内部Web应用程序的安全实践

时间:2011-01-11 18:40:47

标签: security

我是一名开发基于Web的内部应用程序的开发人员,我有责任确保系统安全。我没有这方面的经验,但我仍然想尽我所能:我正在阅读OWASP的指南(http://surfnet.dl.sourceforge.net/project/owasp/Guide/2.0 .1 / OWASPGuide2.0.1.pdf),但有很多信息要处理,不幸的是截止日期是截止日期。

Stack Overflow的知识渊博的用户可以在我的设计中挖洞并告诉我缺乏理解的地方吗?如果整个想法存在根本缺陷,那么也应该理解这一点。感谢您的任何意见。

此应用程序在内部托管,即使通过我们的无线网络访问,也不应在外部显示。不过,我相信我们的网络工程师可以解决这个问题。

此应用程序的用户只是此公司环境中所有员工的子集。此外,即使是授权用户也应仅限于与他们相关的信息(这主要是应用程序级别的问题,但我想确保无法利用漏洞)。

内部Web应用程序的安全框架(由新手提供)

与Web服务器的所有通信都通过HTTPS连接完成。

登录

  1. 用户输入通过HTTPS连接发布的名称和密码
  2. 如果名称和密码正确,请生成令牌并将其存储在cookie中。还将cookie存储在数据库中以供将来查找。令牌应具有过期日期,并且仅与生成它的用户相关联。
    1. 检查提供的令牌是否仍然有效(未过期)
    2. 检查令牌对发出请求的用户是否有效
    3. 如果一切都结束,请再次刷新令牌的有效期30分钟(或左右)
    4. 否则,拒绝访问

3 个答案:

答案 0 :(得分:0)

重要考虑因素:整个会话必须通过SSL。 Firesheep非常清楚地证明,能够嗅到cookie(与受害者在同一网络上)会让你的用户对会话劫持开放。

安全不仅仅是登录。您至少需要阅读SQL InjectionCross-Site Scripting Attacks(对网络应用程序最常见的两种攻击)。

答案 1 :(得分:0)

听起来不错 令牌可以是签名的到期日期(使用存储在服务器上的私钥签名),也可以是存储在数据库中的加密安全随机字节序列。

除非令牌特定于IP地址,否则所有内容都必须通过SSL完成。


独立于身份验证,您还需要注意SQL注入,CSRF,XSS和其他安全漏洞。

答案 2 :(得分:0)

调查CSRF次攻击。他们绕过了cookie检查和公司防火墙。