我应该了解哪些常见的网络漏洞?

Bri*_*ahy 52 security testing

在网络编程方面,我还很绿,我把大部分时间花在了客户端应用程序上.所以我很好奇我应该在我的网站上担心/测试的常见漏洞.

Ada*_*vis 34

我在这里发布了OWASP Top 2007缩写列表,这样人们就不必查看另一个链接,以防万一.

跨站点脚本(XSS)

  • 每当应用程序获取用户提供的数据并将其发送到Web浏览器而不首先验证或编码该内容时,就会出现XSS漏洞.XSS允许攻击者在受害者的浏览器中执行脚本,这可能会劫持用户会话,破坏网站,可能会引入蠕虫等.

注射缺陷

  • 注入漏洞,特别是SQL注入,在Web应用程序中很常见.当用户提供的数据作为命令或查询的一部分发送到解释器时,会发生注入.攻击者的恶意数据欺骗解释器执行非预期的命令或更改数据.

恶意文件执行

  • 易受远程文件包含(RFI)攻击的代码允许攻击者包含恶意代码和数据,从而导致破坏性攻击,例如整个服务器泄露.恶意文件执行攻击会影响PHP,XML和任何接受用户文件名或文件的框架.

不安全的直接对象参考

  • 当开发人员将对内部实现对象(如文件,目录,数据库记录或键)的引用公开为URL或表单参数时,就会发生直接对象引用.攻击者可以在未经授权的情况下操纵这些引用来访问其他对象.

跨站请求伪造(CSRF)

  • CSRF攻击强制登录受害者的浏览器向易受攻击的Web应用程序发送预先验证的请求,然后强制受害者的浏览器执行恶意操作以使攻击者受益.CSRF可以像它攻击的Web应用程序一样强大.

信息泄漏和错误处理不当

  • 应用程序可能会无意中泄露有关其配置,内部工作或通过各种应用程序问题侵犯隐私的信息.攻击者利用此弱点窃取敏感数据,或进行更严重的攻击.

身份验证和会话管理中断

  • 帐户凭据和会话令牌通常未得到适当保护.攻击者会破坏密码,密钥或身份验证令牌以承担其他用户的身份.

不安全的加密存储

  • Web应用程序很少正确使用加密功能来保护数据和凭据.攻击者使用受弱保护的数据进行身份盗用和其他犯罪,如信用卡欺诈.

不安全的通信

  • 当需要保护敏感通信时,应用程序经常无法加密网络流量.

无法限制URL访问

  • 通常,应用程序仅通过阻止向未授权用户显示链接或URL来保护敏感功能.攻击者可以通过直接访问这些URL来利用此漏洞访问和执行未经授权的操作.

开放式Web应用程序安全项目

-亚当


dra*_*ank 29

除了用于Web开发的大量其他有用的安全信息之外,OWASP还会列出十大网络攻击列表以供我们观看.


Rob*_*per 10

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}   
Run Code Online (Sandbox Code Playgroud)


小智 10

每个人都会说"SQL注入",因为它是最可怕的漏洞,也是最容易理解的漏洞.跨站点脚本(XSS)将排在第二位,因为它也很容易理解."输入验证不良"不是漏洞,而是对安全最佳实践的评估.

让我们从不同的角度来试试这个.以下功能在Web应用程序中实现时可能会让您感到困惑:

  • 动态SQL(例如,UI查询构建器).到目前为止,您可能知道在Web应用程序中使用SQL的唯一可靠安全方法是使用参数化查询,您可以将查询中的每个参数显式绑定到变量.我看到网络应用程序最常破坏此规则的地方是恶意输入不是明显的参数(如名称),而是查询属性.一个明显的例子是您在搜索网站上看到的类似iTunes的"智能播放列表"查询构建器,其中where子句运算符等内容直接传递给后端.翻转的另一个好方法是表列排序,在这里您可以看到在HTTP参数中暴露的DESC之类的东西.

  • 上传文件.文件上传会让人大吃一惊,因为文件路径名看起来像URL路径名,并且因为Web服务器只需将URL瞄准文件系统上的目录就可以轻松实现"下载"部分.我们测试的10个上传处理程序中有7个允许攻击者访问服务器上的任意文件,因为应用程序开发人员假定相同的权限应用于文件系统"open()"调用,如同应用于查询一样.

  • 密码存储.如果您的应用程序在丢失时可以将我的原始密码邮寄给我,那么您将失败.密码存储有一个安全可靠的答案,就是bcrypt; 如果你使用PHP,你可能想要PHPpass.

  • 随机数生成.对Web应用程序的经典攻击:重置另一个用户的密码,并且,由于该应用程序正在使用系统的"rand()"函数,该函数不具有加密性,因此密码是可预测的.这也适用于您正在进行加密的任何地方.顺便说一句,你不应该这样做:如果你在任何地方都依赖加密,你很可能很脆弱.

  • 动态输出.人们对输入验证过于信任.您擦除用户输入所有可能元字符的机会很少,特别是在现实世界中,元字符是用户输入的必要部分.一种更好的方法是使用一致的过滤数据库输出的方法并将它们转换为HTML实体,如quot,gt和lt.Rails会自动为您完成此操作.

  • 电子邮件.许多应用程序实现某种出站邮件功能,使攻击者能够创建匿名帐户,或者根本不使用任何帐户,将攻击者控制的电子邮件发送到任意电子邮件地址.

除了这些功能之外,您可能在应用程序中犯的第一个错误是在某处公开数据库行ID,以便用户X只需将数字从"5"更改为"6"即可查看用户Y的数据.