13 OWASP TOP10（2017年）
注：OWASP是世界上最知名的Web安全与数据库安全研究组织
参考文档：
https://blog.csdn.net/lifetragedy/article/details/52573897
http://www.sohu.com/a/139968130_669829
13.1 SQL注入
通过sql语句，插入到web表单提交或输入域名或页面请求的查询字符串，达到欺骗服务器执行恶意sql语句的目的。
（网站，数据库代码的不严谨性，从而出现漏洞，被攻击者利用，进行表单提交，从而获取对应的信息或者获取对应的权限。）
13.1.1 防护
1、 不要相信用户的输入，对用户输入要校验以及有长度限制，对对应的符号进行转换。
2、 不要使用管理员账号链接数据库，为不同的应用创建单独的权限。
3、 不要使用动态拼装sql语句
4、 不要直接存放机密信息，要进行相应的加密。
5、 应用返回的错误信息不要太详细。
6、 使用对应的检测工具进行sql注入攻击检查，如jsky
13.2 失效的身份认证和会话管理
（本该失效的身份认证却没有失效，从而被恶意攻击者利用）
13.2.1 参考文档：
https://blog.csdn.net/quiet_girl/article/details/50585934
身份认证：更多时候体现在用户登陆需要账号、密码，为了防止穷举法，添加验证码，或者证书，或者类似网银U盾支付确认的物理认证。
会话管理，HTTP本身是无状态的，利用会话管理机制来实现连接识别。身份认证的结果往往是获得一个令牌，通常放在cookie中，之后对用户身份的识别根据这个授权的令牌进行识别，而不需要每次都要登陆。
13.2.2 一些存在此漏洞的例子：
1、用户更改密码之前不验证用户，而是依靠会话的IP地址;
2、没有会话超时限制;
3、用户忘记密码后，密码找回功能太过简单。
4、。。。
例1：应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。
例2：机票预订应用程序支持URL重写，把会话ID放在URL里：http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。
例3：内部或外部攻击者进入系统的密码数据库. 存储在数据库中的用户密码没有被加密, 所有用户的密码都被攻击者获得。
13.2.3 如何验证程序是否存在失效的认证和会话管理？
最需要要保护的数据是认证凭证(credentials) 和会话ID。
1.当存储认证凭证时，是否总是使用hashing或加密保护吗?
2. 认证凭证是否可猜测，或者能够通过薄弱的的帐户管理功能
(例如账户创建、密码修改、密码恢复, 弱会话ID)重写？
3.会话ID是否暴露在URL里(例如, URL重写) ？
4.会话ID是否容易受到会话固定(session fixation) 的攻击?
5.会话ID会超时吗? 用户能退出吗?
6.成功注册后,会话ID会轮转吗?
7. 密码、会话ID和其他认证凭据是否只通过TLS连接传输？
13.2.4 如何防范：
1、区分公共区域和受限区域
站点的公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。考虑一个典型的零售网站。您可以匿名浏览产品分类。当您向购物车中添加物品时，应用程序将使用会话标识符验证您的身份。最后，当您下订单时，即可执行安全的交易。这需要您进行登录，以便通过SSL 验证交易。
将站点分割为公共访问区域和受限访问区域，可以在该站点的不同区域使用不同的身份验证和授权规则，从而限制对 SSL 的使用。使用SSL 会导致性能下降，为了避免不必要的系统开销，在设计站点时，应该在要求验证访问的区域限制使用 SSL。
2、对最终用户帐户使用帐户锁定策略
当最终用户帐户几次登录尝试失败后，可以禁用该帐户或将事件写入日志。如果使用 Windows 验证(如 NTLM 或Kerberos协议)，操作系统可以自动配置并应用这些策略。如果使用表单验证，则这些策略是应用程序应该完成的任务，必须在设计阶段将这些策略合并到应用程序中。
请注意，帐户锁定策略不能用于抵制服务攻击。例如，应该使用自定义帐户名替代已知的默认服务帐户(如IUSR_MACHINENAME)，以防止获得 Internet 信息服务 (IIS) Web服务器名称的攻击者锁定这一重要帐户。
3、支持密码有效期
密码不应固定不变，而应作为常规密码维护的一部分，通过设置密码有效期对密码进行更改。在应用程序设计阶段，应该考虑提供这种类型的功能。
4、能够禁用帐户
如果在系统受到威胁时使凭证失效或禁用帐户，则可以避免遭受进一步的攻击。
5、不要在用户存储中存储密码
如果必须验证密码，则没有必要实际存储密码。相反，可以存储一个单向哈希值，然后使用用户所提供的密码重新计算哈希值。为减少对用户存储的词典攻击威胁，可以使用强密码，并将随机salt 值与该密码结合使用。
6、要求使用强密码
不要使攻击者能轻松破解密码。有很多可用的密码编制指南，但通常的做法是要求输入至少 8位字符，其中要包含大写字母、小写字母、数字和特殊字符。无论是使用平台实施密码验证还是开发自己的验证策略，此步骤在对付粗暴攻击时都是必需的。在粗暴攻击中，攻击者试图通过系统的试错法来破解密码。使用常规表达式协助强密码验证。
7、不要在网络上以纯文本形式发送密码
以纯文本形式在网络上发送的密码容易被窃听。为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
8、保护身份验证 Cookie
身份验证 cookie被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护验证票证。另外，还应限制验证票证的有效期，以防止因重复攻击导致的欺骗威胁。在重复攻击中，攻击者可以捕获cookie，并使用它来非法访问您的站点。减少 cookie 超时时间虽然不能阻止重复攻击，但确实能限制攻击者利用窃取的 cookie来访问站点的时间。
9、使用 SSL 保护会话身份验证 Cookie
不要通过 HTTP 连接传递身份验证 cookie。在授权 cookie 内设置安全的 cookie 属性，以便指示浏览器只通过HTTPS 连接向服务器传回 cookie。
10、对身份验证 cookie 的内容进行加密
即使使用 SSL，也要对 cookie 内容进行加密。如果攻击者试图利用 XSS 攻击窃取cookie，这种方法可以防止攻击者查看和修改该 cookie。在这种情况下，攻击者仍然可以使用 cookie 访问应用程序，但只有当cookie 有效时，才能访问成功。
11、限制会话寿命
缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短，攻击者捕获会话 cookie并利用它访问应用程序的时间越有限。
12、避免未经授权访问会话状态
考虑会话状态的存储方式。为获得最佳性能，可以将会话状态存储在 Web 应用程序的进程地址空间。然而这种方法在 Web场方案中的可伸缩性和内涵都很有限，来自同一用户的请求不能保证由同一台服务器处理。在这种情况下，需要在专用状态服务器上进行进程外状态存储，或者在共享数据库中进行永久性状态存储。ASP.NET支持所有这三种存储方式。
对于从 Web 应用程序到状态存储之间的网络连接，应使用 IPSec 或 SSL 确保其安全，以降低被窃听的危险。另外，还需考虑Web 应用程序如何通过状态存储的身份验证。
在可能的地方使用 Windows验证，以避免通过网络传递纯文本身份验证凭据，并可利用安全的 Windows 帐户策略带来的好处。
原文出自比特网，转载请保留原文链接：http://network.chinabyte.com/249/12368749.shtml
除了上述之外，这里根据个人经验对防范措施作出一点补充：
1.不使用简单或可预期的密码回复问题。
2. 登录出错时不给过多或者过于详细的提示信息。
3. 验证成功后更换sessionID。
13.3 跨站脚本攻击（xss）
（利用合法用户获取信息或权限）
恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。和SQL注入一样，利用web页面代码不严谨，不完善的漏洞。
13.3.1 概念：
XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而JavaScript是新型的“ShellCode”。
13.3.2 危害
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
13.3.3 Xss分成两大类：
两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。
另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。
13.3.4 XSS分为：存储型和反射型
存储型XSS：存储型XSS，持久化，代码是存储在服务器中的，如在个人信息或发表文章等地方，加入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易造成蠕虫，盗窃cookie（虽然还有种DOM型XSS，但是也还是包括在存储型XSS内）。
反射型XSS：非持久化，需要欺骗用户自己去点击链接才能触发XSS代码（服务器中没有这样的页面和内容），一般容易出现在搜索页面。
13.4 不安全的对象直接引用（IDOR）
（简单的说，就是已授权的，可信任的账号在登陆之后，可以修改或获取本不属于自己权限的信息。）
（比如说，用户在登陆之后，本想修改自己的用户名，但他却利用该漏洞修改别人的用户名。）
（比如，修改某产品的价格）
IDOR将允许一名授权用户获取其他用户的信息，意指一个已经授权的用户通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。Web应用往往在生成Web页面或服务时会用它的真实名字，且并不会对所有目标对象的请求访问进行用户权限检测，所以这就造成了不安全的对象直接引用的漏洞。换句话说，不安全的直接对象引用漏洞将允许攻击者通过页面或服务向特殊对象资源发送访问请求，如果系统不会对请求发送者的身份权限进行合理认证的话，就说明这个系统中存在不安全的直接对象引用。
不安全的直接对象引用允许攻击者绕过网站的身份验证机制，并通过修改指向对象链接中的参数值来直接访问目标对象资源，这类资源可以是属于其他用户的数据库条目以及服务器系统中的隐私文件等等。导致这种情况出现的原因是，系统在接受用户输入并利用输入信息获取对象之前没有对用户身份权限进行检测。
应用程序在SQL查询语句中直接使用了未经测试的数据，而攻击者可以利用这一点来访问数据库中的其他账号数据。
13.5 伪造跨站请求（csrf）
（伪造成合法用户获取信息）
CSRF（Cross Site RequestForgery），跨站请求伪造，是利用受害者尚未失效的身份验证信息，诱导其访问其他包含非法、恶意代码的页面，在受害者不知情的情况下向服务器发送请求，完成改密、转账等行为。跨站请求伪造是一种十分危险的Web安全攻击，利用的是网站对用户浏览器的信任，通常攻击者会通过电子邮件、聊天工具或者论坛来发送链接。如果使用不可见的img标签（宽高为0或者display: none）可以在受害者不点击链接的情况下自动发出HTTP请求，因为浏览器不会判断img的src属性是否指向一个无害的图片，并且图片和表单在同一个主机域中。
13.5.1 防护
1. 使用post，不使用get修改信息
2. 验证码，所有表单的提交需要验证码，但是貌似用起来很麻烦，所以一些关键的操作可以
3. 在表单中预先植入一些加密信息，验证请求是此表单发送
13.6 安全错误配置
（出现这个漏洞的情况比较多，任何的一个应用平台，比如说习惯的在登陆界面保存密码，或密码复杂度简单等）
13.6.1 攻击场景举例：
场景1：应用服务器管理控制台被自动安装并且没有被移除。默认账户没有改变。攻击者在你服务器上发现了标准管理页面，使用默认密码进登录，并进行接管。
场景2：目录监听在你服务器上没有被禁用。攻击者发现她可以轻松的列出所有文件夹去查找文件。攻击者找到并且下载你所有的编译过的Java类，然后她进行反编译和逆向工程以获得你所有的代码。然后她在你应用中发现了一个访问控制漏洞。
场景3:应用服务器配置允许堆栈信息返回给用户，可能泄露潜在的漏洞。攻击者爱死错误信息了~。
场景4:应用程序中带有样例程序，并且没有被从你的生产环境服务器上移除。样例程序中可能包含很多广为人知的安全漏洞，
攻击者会使用它们去威胁你的服务器。
13.6.2 防护措施
1.一个可重复的固化处理，允许快速且容易地正确部署到另外一个环境的方法需要被固化下来。开发，质保，以及生产环境应该被全面地同等地配置（在每个环境中使用不同的密码）。这个处理应该使安装一个新安全环境的代价最小化。
2.保持了解最新软件更新、补丁以及及时部署到所有发布环境中，同时也包括所有代码库。
3.一个健壮的应用架构很关键，以及组件之间的安全隔离。
4.进行扫描和定期的评审以帮助检查未来的错误配置或漏掉的补丁。
13.6.3 导致漏洞的可能性
你的应用是不是未进行对整个应用栈进行正确的安全固化？包括：
1.你的某些软件是否过期了？包括操作系统，网络/应用服务器，数据库管理系统，应用程序，以及所有的代码库（见新A9）。
2.是否某些不需要的特性被开启或安装？例如端口，服务，页面，账户，权限？
3.是否默认账户和他们的密码仍然开启并且未改变？
4.你的错误处理是否暴露出堆栈的痕迹，或者错误信息直接暴露给了用户？
5.在你的开发框架（例如Struts,Spring,ASP.NET）中的安全设置和库没有被设置为安全值？
没有一致的，可重复的应用安全设置处理，系统会处于高风险中
13.6.4 威胁载体:
匿名的外部攻击者以及拥有自己账户的用户，尝试去威胁系统。以及企图掩饰他们行为的内部人员。
攻击媒介:
攻击者访问默认账户，无效页面，没打补丁的漏洞，未受保护的文件及文件夹等，以获得未授权的访问或对应用系统进行了解和分析。
安全弱点：
错误的安全配置可能会发生在应用栈的任何一个层级上，包括平台，Web服务器，应用服务器，数据库，框架，以及自定义代码。开发者以及系统管理员需要协作以确保整个栈被正确的配置。自动扫描器对检测未打补丁，错误配置，使用默认用户，不必要的服务等等很有帮助。
技术影响：
系统会在你完全无察觉的情况下整体受到威胁。你所有的数据都可能被窃取或修改。修复成本可能会很昂贵
应用/业务影响：
系统会在你完全无察觉的情况下整体受到威胁。你所有的数据都可能被窃取或修改。修复成本可能会很昂贵
13.7 限制URL访问失败
包括两个方面：一方面是确实应用没有对URL的访问做出限制，另一方面是程序对URL的访问做出了限制，但是限制没有起到作用。这两种情况都可以导致攻击者访问一些未授权的页面，查询到本不该查询到的信息等。
（主要体现的是，该做的访问策略没有生效，导致用户访问未授权的信息，最简单的就是ACL策略的体现。）
（针对该漏洞，可以实行sql注入或攻击，从而修改、删除重要的信息。）
13.7.1 后果
1、攻击者可以强行访问一些网页或者用户信息等。
2、用户可能会访问到一些需要保护的数据。
3、可以通过URL进行篡改参数的目的，带来严重后果。
13.7.2 防护措施
1、URL参数检查
（1）检查URL中参数信息是否正确：对于URL中的订单号、ID号等可以显示出来的数据，检查是否显示正确，是否正确加密等。
（2）对于需要保护的数据：检查是否没有在URL中显示出来。
2、URL值参数篡改检查
一般对于http://www.example.com/products/1234这样的URL，1234可能代表商品的ID等，可以通过更改此ID查询不同的商品，那么，如果是商品的价格，需要检查是否可以对商品进行更改价格等。
3、权限检查
检查是否可以通过URL直接访问需要登录验证等才可以访问到的页面信息等。
13.8 未验证的重定向和转发
13.8.1 重定向和转发的区别
重定向：服务器根据逻辑，发送一个状态码，告诉浏览器重新去请求目的地址，所以地址栏显示的新的URL。（在客户端完成的）
转发是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,因为这个跳转过程是在服务器实现的，并不是在客户端实现的，所以客户端并不知道这个跳转动作，所以它的地址栏还是原来的地址。（转发是在服务器端完成的）
重定向是两次request 。
第一次，客户端request一个网址,服务器响应，并response回来，告诉浏览器，你应该去别一个网址。
转发是一次请求，因此转发的速度要快于重定向
重定向之后地址栏上的地址会发生变化，变化成第二次请求的地址，转发之后地址栏上的地址不会变化，还是第一次请求的地址
13.8.2 概念：
在Web应用中重定向是非常普遍的，并且通常情况下，重定向所引向的目的是带有用户输入参数的目的URL，而如果这些重定向未被验证，而攻击者就可以引导用户访问他们所要用户访问的站点。
转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时候是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以通过其来绕过认证或是授权检查。
13.8.3 后果：
未验证的重定向和转发可能会使用户进入钓鱼网站，窃取用户信息等，对用户的信息以及财产安全造成严重的威胁。
13.8.4 测试方法
1、如果有代码：浏览代码中含有重定向和转发的内容，看目的url中是否包含用户输入的参数，如果包含，观察目标参数是否在白名单之内，如果涉及到一些安全问题隐私等，需要重新定义目的URL。
2、通过点击操作网站，观察是否产生重定向（HTTP响应代码300-307，通常是302），观察在重定向之前用户输入的参数有没有出现在某一个URL或者很多URL中，如果是这种情况，需要改变URL的目标。
3、如果测试中没有代码，检查所有参数，测试那些看起来像是重定向或者转发的页面。
13.8.5 重定向的深刻理解
通过各种方法将各种网络请求重新定义一个方向，转到其他位置。
比如：网站调整或页面变更，网页被移动到了新的地址，但旧地址一时太熟悉，人们还没熟悉，没适应新地址，可以直接在旧地址做个跳转，也是重定向的一部分。
301代表永久性转移(Permanently Moved)，301重定向是网页更改地址后对搜索引擎友好的最好方法，只要不是暂时搬移的情况，都建议使用301来做转址。
302代表暂时性转移(Temporarily Moved )，在前些年，不少Black Hat SEO（黑帽SEO）曾广泛应用这项技术作弊，目前，各大主要搜索引擎均加强了打击力度，像Google前些年对域名之王（Business）以及近来对BMW德国网站的惩罚。即使网站客观上不是spam，也很容易被搜寻引擎容易误判为spam而遭到惩罚。
（Apache应用很多重定向）
13.8.6 转发的深刻理解
客户端发送请求，Servlet做出业务逻辑处理。
Servlet调用forword()方法，服务器Servlet把目标资源返回给客户端浏览器。
Web应用在响应客户端的一个请求时，有可能响应过程很复杂，需要多个Web组件共同协作，才能生成响应结果。此时，可以使用转发技术。
在同一个web应用内部，一个组件将未完成的任务转发给另外一个组件，由另外一个组件进行后续的处理并生成响应结果。
最常见的情况是一个Servlet完成了业务逻辑的处理，将数据展现交给一个JSP来完成。
13.9 应用已知脆弱性的组件
13.9.1 概念
组件：比如库文件，框架和其他软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。
（比如某些已知的组件是有漏洞的，但开发依然安装并使用了该组件。）
13.9.2 防护
1、 识别正在使用的组件和版本，包括所有的依赖（插件及其版本）
2、 监控这些在公共数据库中、项目的邮件列表、以及安全邮件列表的组件的安全性，并保持他们更新到最新。
3、 建立安全策略来管理组件的使用，如需要一定的软件开发实践，通过安全测试，和可接受的许可证。
13.10 敏感数据暴露
13.10.1 概念
Web应用程序没有做到正确保护敏感数据：比如账号密码，身份信息，加密密钥，系统版本，数据库版本等都属于敏感信息。
13.10.2 防护
1、 针对数据，进行加密存储。
2、 敏感数据传输，进行SSL加密通道传输
3、 应用程序出错，不要提示过多信息，容易被攻击者进行针对性判断处理。
4、 敏感数据，尽量不要传输到web客户端，严格控制访问权限。