OWASP TOP 10 (2013)

1. 注入

注入攻击漏洞，例如SQL，OS 以及LDAP注入。这些攻击发生在当不可信的数据作为命令或者查询语句的一部分，被发送给解释器的时候。攻击者发送的恶意数据可以欺骗解释器，以执行计划外的命令或者在未被恰当授权时访问数据。

2. 失效的身份认证和会话管理

身份认证:

最常见的是登录功能,往往是提交用户名和密码,在安全性要求更高得情况下,有防止密码暴力破解的验证码,基于用户端的证书,物理口令卡等

会话管理:

HTTP本身是无状态的,利用会话管理机制来实现连接识别.身份认证的结果往往是获得一个令牌,通常放在cookie中,之后对用户身份的识别根据这个授权的令牌进行识别,而不需要每次都要登录.

失效的身份认证和会话管理:

与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，这就导致了攻击者破坏密码、密匙、会话令牌或攻击其他的漏洞去冒充其他用户的身份。

1. 用户更改密码之前不需要验证,而是依靠会话的ip地址
2. 没有会话超时限制
3. 密码找回功能过于简单
4. session放在URL中

3. 跨站脚本攻击 (Xss)

当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（简称XSS）。XSS允许攻击者在受害者的浏览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向至恶意网站。

4. 不安全的直接对象引用

指一个已经授权的用户，通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。
当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数据库密匙，就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些引用去访问未授权数据。

不安全的直接对象引用实例

某网站的新闻检索功能可搜索指定日期的新闻，但其返回的URL中包含了指定日期新闻页面的文件名：http://example.test/online/news.asp?item=28Jan2016.html。
攻击者可以尝试不同的目录层次来获得系统文件win.ini，例如，http://example.test/ online/news.asp? item=../../ winnt/win.ini。

防御措施

1. 避免在URL或网页中直接引用内部文件名或数据库关键字。
2. 可使用自定义的映射名称来取代直接对象名，例如， http://example.test/online/news.asp?item=0245等
3. 锁定网站服务器上的所有目录和文件夹，设置访问权限。
4. 验证用户输入和URL请求，拒绝包含./或../的请求。

5. 安全配置错误

好的安全需要对应用程序、框架、应用程序服务器、web服务器、数据库服务器和平台定义和执行安全配置。由于许多设置的默认值并不是安全的，因此，必须定义、实施和维护这些设置。这包含了对所有的软件保持及时地更新，包括所有应用程序的库文件。

安全配置错误实例

数据库的帐号是不是默认为“admin”，密码（还有端口号）是不是直接写在配置文件里而没有进行加密，这些都是属于安全配置错误，会对应用的安全问题造成威胁。

防御措施

1. 配置所有的安全机制
2. 关掉所有不使用的服务
3. 设置角色权限帐号
4. 使用日志和警报
5. 所有错误只显示友好信息，不显示任何与实际错误相关的信息

6. 敏感信息泄露

许多Web应用程序没有正确保护敏感数据，如信用卡，税务ID和身份验证凭据。攻击者可能会窃取或篡改这些弱保护的数据以进行信用卡诈骗、身份窃取，或其他犯罪。敏感数据值需额外的保护，比如在存放或在传输过程中的加密，以及在与浏览器交换时进行特殊的预防措施。

实例

1. 一个应用程序加密存储在数据库的信用卡信息，以防止信用卡信息暴露给最终用户。但是，数据库设置为对信用卡表列的查询进行自动解密，这就使得SQL注入漏洞能够获得所有信用卡信息的明文。该系统应该被设置为前端应用程序使用公钥对信用卡信息加密，后端应用程序只能使用私钥解密。
2. 一个网站上所有需要身份验证的网页都没有使用SSL。攻击者只需监控网络数据流（比如一个开放的无线网络或其社区的有线网络），并窃取一个已验证的受害者的会话cookie。然后，攻击者利用这个cookie执行重放攻击并接管用户的会话从而访问用户的隐私数据。
3. 密码数据库使用unsalted的哈希算法去存储每个人的密码。一个文件上传漏洞使黑客能够获取密码文件。所有这些unsalted哈希的密码通过彩虹表暴力破解方式破解。

7.功能级访问控制缺失

大多数Web应用程序在功能在UI中可见以前，验证功能级别的访问权限。但是，应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证，攻击者能够伪造请求以在未经适当授权时访问功能。

实例

1. 攻击者仅仅直接浏览目标网址。例如下面的两个网址都需要身份验证。同时问“admin_getappInfo”页面还需要管理员权限。
   http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
   如果未认证的用户可以访问上述任一页面，这就是漏洞。如果通过验证的非管理员用户也能允许访问“admin_getappInfo”页面，这同样是个漏洞。这个漏洞可能会将攻击者引向更多保护不当的管理页面。
2. 一个页面提供了“action”参数给某个特定的功能调用，并且不同的操作需要不同的角色。如果没有进行角色检查，这也是漏洞。

解决方法

对一些需要权限才可以访问的目录、网页等做相应的验证处理，保证只有合法用户才可以访问，没有权限的用户给出相应的友好提示，提示信息也应当注意不能出现任何包含权限等信息的内容。

8. 跨站请求伪造 (CSRF)

一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的HTTP请求，包括该用户的会话cookie和其他认证信息，发送到一个存在漏洞的web应用程序。这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求，而这些请求会被应用程序认为是用户的合法请求。

9. 使用含有已知漏洞的组件

组件，比如：库文件、框架和其它软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，并使一系列可能的攻击和影响成为可能。

解决措施

尽量使用比较安全的组件，另外，对于组件的接口的安全性等也需要测试.

10. 未验证的重定向和转发

重定向和转发的区别

解释一
一句话，转发是服务器行为，重定向是客户端行为。为什么这样说呢，这就要看两个动作的工作流程：
转发过程：客户浏览器发送http请求——》web服务器接受此请求——》调用内部的一个方法在容器内部完成请求处理和转发动作——》将目标资源发送给客户；在这里，转发的路径必须是同一个web容器下的url，其不能转向到其他的web路径上去，中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。
重定向过程：客户浏览器发送http请求——》web服务器接受后发送302状态码响应及对应新的location给客户浏览器——》客户浏览器发现是302响应，则自动再发送一个新的http请求，请求url是新的location地址——》服务器根据此请求寻找资源并发送给客户。在这里location可以重定向到任意URL，既然是浏览器重新发出了请求，则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

解释二
重定向，其实是两次request
第一次，客户端request A,服务器响应，并response回来，告诉浏览器，你应该去B。这个时候IE可以看到地址变了，而且历史的回退按钮也亮了。重定向可以访问自己web应用以外的资源。在重定向的过程中，传输的信息会被丢失。
例子：
response.sendRedirect(“loginsuccess.jsp”);
请求转发是服务器内部把对一个request/response的处理权，移交给另外一个
对于客户端而言，它只知道自己最早请求的那个A，而不知道中间的B，甚至C、D。传输的信息不会丢失。
例子：
RequestDispatcher dis=request.getRequestDispatcher(“loginsuccess.jsp”);
Dis.forward(request,response);

解释三
假设你去办理某个执照
重定向：你先去了A局，A局的人说：“这个事情不归我们管，去B局”，然后，你就从A退了出来，自己乘车去了B局。
转发：你先去了A局，A局看了以后，知道这个事情其实应该B局来管，但是他没有把你退回来，而是让你坐一会儿，自己到后面办公室联系了B的人，让他们办好后，送了过来。
重定向:重定向是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL。（重定向是在客户端完成的）
转发:转发是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,因为这个跳转过程实在服务器实现的，并不是在客户端实现的所以客户端并不知道这个跳转动作，所以它的地址栏还是原来的地址。（转发是在服务器端完成的）

未验证的重定向和转发的概念

Web应用程序经常将用户重定向和转发到其他网页和网站，并且利用不可信的数据去判定目的页面。如果没有得到适当验证，攻击者可以重定向受害用户到钓鱼软件或恶意网站，或者使用转发去访问未授权的页面。
在Web应用中重定向是非常普遍的，并且通常情况下，重定向所引向的目的是带有用户输入参数的目的URL，而如果这些重定向未被验证，而攻击者就可以引导用户访问他们所要用户访问的站点。
转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时候是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以通过其来绕过认证或是授权检查。

实例

1. 应用程序有一个名为“redirect.jsp”的页面，该页面有一个参数名是“url”。攻击者精心制作一个恶意URL将用户重定向到一个恶意网站，执行钓鱼攻击并安装恶意程序。http://www.example.com/redirect.jsp?url=evil.com
2. 应用程序使用转发在网站的不同部分之间发送请求。为了帮助实现这一功能，如果一个交易成功了的话，一些网页就会发送一个参数给用户，用于指定用户的下一个页面。在这种情况下,攻击者制作一个URL, 用于绕过应用程序的访问控制检查,并将他转发给一个他通常不能访问的管理功能。
   http://www.example.com/boring.jsp?fwd=admin.jsp

防御措施

1. 尽量避免使用重定向和转发机制，如果使用了，那么在定义目标URL的时候不要包含用户参数。
2. 如果一定要保护用户输入的参数，那么: 对每个参数都必须进行验证以确保它的合法性和正确性，或是在服务端提供映射机制，将用户的选择参数转变为真正的白名单目标页面。