OWASP，全称是：Open Web Application Security Project，翻译为中文就是：开放式Web应用程序安全项目，是一个非营利组织，不附属于任何企业或财团，这也是该组织可以不受商业控制地进行安全开发及安全普及的重要原因。它应用于web扫描和攻击的安全工具，同时也是开源的，在截断代理以及扫描攻击上是比较强大的。
OWASP扫描漏洞范围：
1—注入
2—失效的身份认证会话管理
3—跨站脚本、XSS
4—不安全的直接对象引用
5—安全配置错误
6—敏感信息泄漏
7—功能级访问控制缺失
8—跨站请求伪造(CSRF)
9—使用含有已知漏洞的组件
10—未验证的重定向和转发
漏洞详解：
1.注入：注入攻击漏洞，例如SQL，OS以及 LDAP注入。这些攻击发生在当不可信的数据作为命令或者查询语句的一部分，被发送给解释器的时候。攻击者发送的恶意数据可以欺骗解释器，以执行计划外的命令或者在未被恰当授权时访问数据。
SQL注入
SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行指定的SQL语句。它是利用现有应用程序，将SQL语句注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入SQL语句得到一个存在安全漏洞的网站上的数据，而不是按照设计者意图去执行SQL语句。
SQL注入漏洞原理
SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。
SQL注入的产生原因
①不当的类型处理；
②不安全的数据库配置；
③不合理的查询集处理；
④不当的错误处理；
⑤转义字符处理不合适；
⑥多个提交处理不当。
SQL注入漏洞对于数据安全的影响
1.数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。
2.网页篡改：通过操作数据库对特定网页进行篡改。
3.网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。
4.数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被窜改。
5.服务器被远程控制，被安装后门。经由数据库服务器提供的操作
6.系统支持，让黑客得以修改或控制操作系统。
7.破坏硬盘数据，瘫痪全系统。
SQL注入漏洞的方法
1.数字注入
请求：ccc/sql/article.php?id=1，这是一个get型接口，发送这个请求相当于调用一个查询语句：
SELECT * FROM article WHERE id =1
正常情况下，应该返回一个id=1的文章信息。那么，如果请求改为ccc/sql/article.php?id=-1 OR 1 =1，这就是一个SQL注入攻击了，可能会返回所有文章的相关信息。为什么会这样呢？这是因为，id = -1永远是false，1=1永远是true，所有整个where语句永远是ture，所以where条件相当于没有加where条件，那么查询的结果相当于整张表的内容。
2.字符串注入
假设有一个登录接口，需要输入用户名和密码并且提交，一般情况下是一个post请求，登录时调用接口ccc/sql/login.html，首先连接数据库，然后后台对post请求参数中携带的用户名、密码进行参数校验，即sql的查询过程。假设正确的用户名和密码为test和123456，输入正确的用户名和密码,提交，相当于调用了以下的SQL语句：
SELECT * FROM user WHERE username = ‘test’ ADN password = ‘123456’
由于用户名和密码都是字符串，SQL注入方法即把参数携带的数据变成mysql中注释的字符串。mysql中有2种注释的方法：
1）#：#后所有的字符串都会被当成注释来处理
用户名输入：user’#（单引号闭合user左边的单引号），密码随意输入，如：999，然后点击提交按钮。等价于SQL语句：
SELECT * FROM user WHERE username = ‘user’#'ADN password = ‘999’
#后面都被注释掉了，相当于：
SELECT * FROM user WHERE username = ‘user’
2）-- （–后面有个空格）：-- 后面的字符串都会被当成注释来处理
用户名输入：user’-- （注意–后面有个空格，单引号闭合user左边的单引号），密码随意输入，如：999，然后点击提交按钮。等价于SQL语句：
SELECT * FROM user WHERE username = ‘user’-- 'AND password = ‘999’
– 后面都被注释掉了，相当于：
SELECT * FROM user WHERE username = ‘user’
因此，以上两种情况可能输入一个错误的密码或者不输入密码就可登录用户名为’user’的账号，这是十分危险的事情。
2.失效的身份认证和会话管理：
身份认证一般仅仅用于登录的过程，用户需提交用户名和口令，对于安全性要求更高的身份认证，有验证码，基于客户端的证书，口令卡等等。HTTP本身是无状态的，利用会话管理机制来实现连接识剔。当用户完成了身份验证开始访问网站时，不可能每次进行网页的访问都重新进行一次身份验证，因此，当认证成功后，系统会给用户分配一个令牌，每个令牌都是唯一并且不可预测的，这个令牌通常放在cookie中，之后用户在访问新的网页时，对用户身份的识别只需对这个授权的令牌进行识别。
开发人员通常只关注Web应用程序的功能，由于这个原因，开发者通常会建立自定义的认证和会话管理方案。但要正确实现这些方案却很难，结果这些自定义的方案往往在退出、口令管理、超时、记住我、秘密问题、账户更新等存在漏洞。因为这些每一个实现都不同，要找出这些漏洞有时会很难。
用户口令和用户令牌是整个Web应用最重要的部分，攻击者往往会采用网络嗅探、暴力攻击、社会工程等手段来获取这些信息。与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，用户口令或者用户令牌在会话过程中丢失，这就导致了攻击者破坏口令、密匙、会话令牌或攻击其他的漏洞去冒充其他用户的身份，就会造成失效的身份认证和会话管理。任何匿名的外部攻击者和拥有账号的用户都可能试图盗取其他用户账号。同样也会有内部人员为了掩饰他们的行为而这么做。
(1)可利用性
攻击者使用认证或者会话管理功能中的泄露或漏洞，比如，暴露的账号、口令等来假冒用户。
(2)影响
这些漏洞可能导致部分甚至全部账户遭受攻击。一旦成功，攻击者能执行受害用户的任何操作。因此特权账户是常见的攻击对象。
(3)例子
用户和服务器登录进行身份验证后，与服务器之间的会话没有会话超时限制，这提高了攻击者在线上使用暴力破解用户口令的可能性。
或者用户使用公共计算机浏览网站，登录验证身份之后，离开时没有退出账户而是选择直接关闭浏览器，使得下一个用户使用相同计算机浏览相同浏览器，可以看到上一个用户的对话。
3.跨站脚本：当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（简称XSS）。XSS允许攻击者在受害者的浏览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向至恶意网站。简单来说，XSS就是通过攻击者精心构造的JS代码注入到网页中，并由浏览器解释运行这段JS代码，以达到恶意攻击浏览器的效果。
XSS分类
反射型XSS
存储型XSS
DOM型XSS
实施XSS攻击需要具备的两个条件
- 需要向Web页面注入精心构造恶意代码
2.对用户的输入没有做过滤，恶意代码能够被浏览器成功的执行
XSS危害
1.盗取各种用户账号
2.窃取用户Cookie资料，冒充用户身份进入网站
3.劫持用户会话，执行任意操作
4.刷流量
5.执行弹窗广告
6.传播蠕虫病毒
7.攻击者能在一定限度内记录用户的键盘输入
4.不安全的直接对象引用：当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数据库密匙，就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些引用去访问未授权数据。
例子：
应用程序在正在访问帐户信息的SQL调用中使用未验证的数据。
String sqlquery = “SELECT * FROM useraccounts WHERE account = ?”;
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter(“acct”));
ResultSet results = st.executeQuery( );
攻击者修改浏览器中的查询参数，指向管理员。
5.安全配置错误：好的安全需要对应用程序、框架、应用程序服务器、web服务器、数据库服务器和平台定义和执行安全配置。由于许多设置的默认值并不是安全的，因此，必须定义、实施和维护这些设置。这包含了对所有的软件保持及时地更新，包括所有应用程序的库文件。
安全配置错误的实例
数据库的帐号是不是默认为“admin”，密码（还有端口号）是不是直接写在配置文件里而没有进行加密，这些都是属于安全配置错误，会对应用的安全问题造成威胁。
安全配置错误的防御措施
配置所有的安全机制
关掉所有不使用的服务
设置角色权限帐号
使用日志和警报
所有错误只显示友好信息，不显示任何与实际错误相关的信息
6.敏感信息泄漏：系统暴露系统内部信息，如网站绝对路径、网页源代码、SQL语句、中间件版本和程序异常等信息。数据库的敏感信息泄露（数据库表段等信息泄露），攻击者可能利用此缺陷对客户端或服务器发送特殊构造的数据，发出攻击，从而了解后台数据库表等信息，对系统安全构成威胁。通过系统暴露出的异常信息，便于入侵者了解系统框架及代码等，从而加大系统被侵入的风险。
解决方案：
1.对用户输入的异常字符做过滤，防止网站绝对路径、网页源代码和SQL语句等信息输出。
2.屏蔽应用程序报错回显，防止恶意用户获得服务器的敏感信息，或对出错信息进行跳转，例如：跳转到自定义404、500等页面。
3.敏感信息包括但不仅限于：
1）网站绝对路径
2）SQL语句
3）中间件信息及版本
4）程序异常、.svn、.git、.DS_Store、.idea等
7.功能级访问控制缺失：大多数Web应用程序在功能在UI中可见以前，验证功能级别的访问权限。但是，应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证，攻击者能够伪造请求以在未经适当授权时访问功能。
功能级访问控制缺失
举一个比较简单的登录的例子，对于登录页面，如果测试功能级访问控制是否缺失，需要测试：
- 合法的用户是否能够正常登录，访问到登录之后的页面。
- 匿名或者攻击者等没有权限的用户是否被拒绝登录，并且不能够访问需要登录才能访问到的页面。
功能级访问控制缺失的测试方法
测试时，应该注意两方面的内容： - 保证合法授权用户可以访问成功。
- 限制非法未授权用户的访问。
8.跨站请求伪造：跨站请求伪造简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
如何确认一个web系统存在CSRF漏洞
1.对目标网站增删改的地方进行标记,并观察其逻辑,判断请求是否可以被伪造
比如修改管理员账号时，并不需要验证旧密码,导致请求容易被伪造;
比如对于敏感信息的修改并没有使用安全的token验证,导致请求容易被伪造;
2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)
虽然退出或者关闭了 浏览器,但cookie仍然有效 ,或者session并没有及时过期 ,导致CSRF攻击变的简单;
9.使用含有已知漏洞的组件：组件，比如：库文件、框架和其它软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，并使一系列可能的攻击和影响成为可能。现在企业都采用托管式的中央组件仓库来存储他们的代码。这些代码中有一些来自私有项目，而更多的则来自于开源代码，在多数情况下，他们只是下载开源代码并导入到其项目中，而不做必要的安全审计。组件越老，就越有可能包含安全缺陷。甚至更糟糕的是， 其中 97% 的下载的组件不能很方便的跟踪和审计。
10.未验证的重定向和转发：Web应用程序经常将用户重定肉和转发到其他网页和网站，并且利用不可信的数据去判定目的页面。如果没有得到适当验证，攻击者可以重定自受害用户到钓鱼软件或恶意网站，或者使用转发去访问未授权的页面。
forward(转发)
是在服务器端的跳转，就是客户端一个请求发给 服务器，服务器直接将请求相关的参数的信息原 封不动的传递到该服务器的其他jsp或servlet去处理。
sendredirect(重定向)
是在客户端的跳转，服务器会返回给客户端一个响应报头和新的url地址，如果服务器端没有特别处理原来的参数就不存在了，浏览器会访问新的url所指向的servlet或jsp，这可能不是原先服务器上的webservice了。
重定向和转发的区别
转发在服务端完成，重定向是在客户端完成的
转发的是同一次请求，重定向是两次不同的请求
转发不会执行转发后的代码，重定向会执行重定向之后的代码
转发地址栏没有变化，重定向地址栏有变化
转发必须是在同一台服务器下完成，重定向可以在不同的服务器下完成
预防机制
最好避免使用重定向和转发。
如果使用了，那么在定义目标url的时候不要包含用户参数
如果一定要包含用户的参数，那么对每个参数都必须进行验证以确保它的正确性和合法性；或是在服务器端提供映射机制，将用户的选择参数转变为真正的目标页面；
