OWASP TOP 10

OWASP TOP 10（2017）

1.SQL注入

SQL注入介绍

1. sql注入是指web应用程序对用户输入的数据合法性没有过滤或者是判断，前端传入的参数是攻击者可以控制，并且参数带入数据库的查询。

2. 条件：2个。

3. Mysql 5.0版本之后，默认在数据库中存放一个information_schema的数据库。里面有Schemata,Tables,Columns。

   Schemata:存储用户创建的所有数据库的库名。记录数据库库名为schemata_name。

   Tables：存储用户创建的所有数据库的库名和表名。记录数据库库名和表名的字段分别为 table_schema ，table_name。

   Columns：存储用户创建的所有数据库的库名、表名和字段名。分别为table_schema ,table_name ,columns_name。

4. 查询所有数据库名

   select schema_name from information_schema.schemata limit 0,1

   查询所有的表名

   select table_name from information_schema.tables limit 0,1

   查询test数据库中的所有表名

   select table_name from information_schema.tables where table_="test" limit 0,1

   查询所有列名（字段名）

   select columns_name from information_schema.columns limit 0,1

   查询test数据库users表中的所有列名（字段名）

   select columns_name from information_schema.columns where table_schema="test" and table_name="users" limit 0,1

5. Limit用法：limit m,n 中m表示记录开始的位置，n表示取几条记录。

6. Version() ：当前mysql的版本。

   Database() ：当前网站使用的数据库。

   User() :当前Mysql的用户名。

   system_user 系统用户名。

   session_user() :连接数据库的用户名。

   current_user ：当前用户名。

7. 注释符号。

   • #

   • -- 空格（空格可以用+代替）

   • /**/

SQL注入流程

注入点探测-信息获取-获取权限。

SQL注入类型

按照注入点类型分类

1. 数字型：类似http://xxx.com/user.php?id=1.利用语句为

   select * from 表名 where id =1 and 1=1

2. 字符型：类似http://xxx.com/user.php?name=admin 。利用语句为

   select * from 表 where name="admin" and 1=1 ' （可以是单引号也可以是双引号）

3. 搜索型：select * from 表 where 字段 like '%关键字%' 。

   select * from 表 where 字段 like '%测试%' and '%1%'='%1%'

按照数据提交的方式分类

1. GET注入：提交数据的方式是GET，注入点在GET的参数部分。比如有这样一个链接 http://xxx.com/news.php?id=1，id是注入点。

2. POST注入：一般在表单中。

3. Cookie注入：HTTP请求的时候会带上客户端的Cookie，注入点存在 Cookie当中的某个字段中。

4. HTTP头部注入：注入点在HTTP请求头部的某个字段中，比如User-Agent。其实Cookie也是头部的一部分。

按照执行效果分类

1. 基于布尔的盲注：可以通过返回页面判断条件的真假。

2. 基于时间的盲注：用条件语句查看时间延迟判断语句是否执行。

3. 基于报错注入：页面会返回错误信息，或者把注入语句的结果直接返回在页面中。

• 联合查询注入：使用union.

• 堆查询注入：同时执行多条语句。

• 宽字节注入。

 

SQL漏洞探测方法

先加单引号、双引号，看看是否报错。然后在url后面加上"and 1=1"、 "and 1=2"看看页面显示是否一样。以及TimingAttack测试（时间盲注）

防御SQL注入

• 找到所有的sql注入漏洞。

• 修补漏洞。

• 使用预编译语句，绑定变量。

• 使用存储过程。

• 检查数据类型。

• 使用安全函数。

 

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

简介

身份认证：常用于系统登录，形式一般为用户名、密码登录方式，在安全性要求较高的情况下还有验证码、客户端证书、Ukey等。

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

原理：程序员再开发Web程序是，开发人员往往只关注Web程序所需要实现的功能。常常会建立自定义的认证和会话方案。但是要正确的实现这些方案是很难的，产生的结果就是在用户：退出、密码管理、超时重登、记住我、密码找回、账户更新等方便出现很多漏洞。因为每一个功能的实现方式都不同，所以想找出这些漏洞有时就很困难。

危害：这些漏洞的存在，就会使得恶意用户有机可乘，可能会被窃取或操纵用户的会话和Cookie，进而模仿网络上的合法用户。比如：窃取用户凭证和会话信息；冒充用户身份查看或变更记录，甚至执行事务；访问未授权的页面和资源；执行超越权限操作。

 

如何判断

1. 用户身份验证凭证没有使用哈希或加密保护。

2. 认证凭证可以猜测，或者能够通过薄弱的账户管理功能（例如账户创建、密码修改、密码恢复、弱会话ID）重写。

3. 会话ID暴露在URL中。

4. 会话ID容易受到会话固定。

5. 会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销的时候没有失效。

6. 成功注册后，会话ID没有轮转。

7. 密码、会话ID和其他认证凭据使用未加密连接传输。

 

如何防范

• 区分公共区域和受限区域：公共区域允许任何用户匿名访问，受限区域只接受特定用户的访问，且通过站点的身份验证。这样也能在不同区域使用不同的身份验证和授权规则，从而限制对SSL的使用。（SSL会使得性能下降）

• 对最终用户账户使用账户锁定策略：多次登录失败，禁用该用户或者将事件写进日志。（攻击时候可以使用自定义的账户名替换成已知的默认服务账户）

• 支持密码有效期。

• 能够禁用账户。

• 不要存储用户密码。

• 要求使用强密码。

• 不要在网络上以纯文本形式发送密码。

• 保护身份验证Cookie。

• 使用SSL保护会话身份验证Cookie。

• 对身份验证cookie的内容加密。（攻击者试图使用XSS攻击窃取cookie）

• 限制会话寿命。

• 避免未经授权访问会话状态。

#####

3.XSS（跨站脚本攻击）

分类

反射型

存储型

Dom型

常用标签

• <script> alert(document.cookie) </script>

  • svg ,img ,body......

XSS插入位置

• 用户输入作为script标签内容。

• 用户输入作为html注释内容。

• 用户输入作为HTML标签的属性名。

• 用户输入作为HTML标签的属性值。

• 用户输入作为HTML标签的名字。

• 直接插入到CSS中。

XSS漏洞挖掘

黑盒测试

常见的业务场景：重灾区（评论区、留言区、个人信息、订单信息等）、针对型（站内信、网页即时通讯、私信、意见反馈等）、存在风险（搜索框、当前目录、图片属性等）。

白盒测试（代码审计）

主要从接收参数的地方和一些关键词入手。PHP常见接收参数的地方有$_GET_、$_POST、$_REQUEST 等。或者是echo这样的输出语句。

XSS攻击过程

反射型：

1. Alice经常浏览某个网站，此网站为Bob所拥有。Bob的站点需要Alice使用用户名/密码进行登录，并存储了Alice敏感信息(比如银行帐户信息)。

2. Tom 发现 Bob的站点存在反射性的XSS漏洞

3. Tom 利用Bob网站的反射型XSS漏洞编写了一个exp，做成链接的形式，并利用各种手段诱使Alice点击

4. Alice在登录到Bob的站点后，浏览了 Tom 提供的恶意链接

5. 嵌入到恶意链接中的恶意脚本在Alice的浏览器中执行。此脚本盗窃敏感信息(cookie、帐号信息等信息)。然后在Alice完全不知情的情况下将这些信息发送给 Tom。

6. Tom 利用获取到的cookie就可以以Alice的身份登录Bob的站点，如果脚本的功更强大的话，Tom 还可以对Alice的浏览器做控制并进一步利用漏洞控制

存储型

1. Bob拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。

2. Tom检测到Bob的站点存在存储型的XSS漏洞。

3. Tom在Bob的网站上发布一个带有恶意脚本的热点信息，该热点信息存储在了Bob的服务器的数据库中，然后吸引其它用户来阅读该热点信息。

4. Bob或者是任何的其他人如Alice浏览该信息之后,Tom的恶意脚本就会执行。

5. Tom的恶意脚本执行后，Tom就可以对浏览器该页面的用户发动一起XSS攻击

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

定义

     不安全的直接对象引用（IDOR）允许攻击者绕过网站的身份验证机制，并通过修改指向对象链接中的参数值来直接访问目标对象资源，这类资源可以是属于其他用户的数据库条目以及服务器系统中的隐私文件等等。
     应用程序在SQL查询语句中直接使用了未经测试的数据，而攻击者可以利用这一点来访问数据库中的其他账号数据。

出现的原因

1. Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。

2. 服务器上的具体文件名、路径或数据库关键字等内部资源被暴露在URL或网页中，攻击者可以尝试直接访问其他资源。

案例（篡改他人邮箱）

• 创建两个账户（123和abc）

• 登录abc的账号，修改邮箱时用bp抓包。

• 将用户标识Id改成123用户的id，然后发包。

• 登录123的账号，发现邮箱被篡改。

• 还可以抓包修改支付金额、用户密码、提权等。

防范

1.使用基于用户或会话的间接对象访问，这样可防止攻击者直接攻击未授权资源 2.访问检查：对任何来自不受信源所使用的所有对象进行访问控制检查 3.避免在url或网页中直接引用内部文件名或数据库关键字 4.验证用户输入和url请求，拒绝包含./ …/的请求

5.安全配置错误

定义

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务，平台，web服务器、应用服务器、数据库、框架、自定义的代码、预安装的虚拟机、容器、存储等。这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。

影响

攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解。

检测场景

 A:应用程序启用或者安装了不必要的安全功能
 B:默认账户名和密码没有修改
 C:应用软件已过期或易受攻击
 D:应用程序服务器，应用程序框架等未进行安全配置。
 E:错误处理机制披露大量敏感信息
 F:对于更新的系统，禁用或不安全地配置安全功能

防御措施

1、 配置所有的安全机制 2、 最小原则，关掉或限制不使用的服务 3、 更改默认账户信息 4、 使用日志和警报 5、 回显信息不显示任何与实际错误相关的信息 6、 检查和修复安全配置项

6.敏感信息泄露

漏洞描述

由于管理员或者技术人员等各种原因导致敏感信息泄露。许多web应用程序和api都无法正确保护敏感数据，攻击者可以通过窃取或修改未改加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

检测方法

 1、 手工挖掘，查看web容器或网页源码代码，可能存在敏感信息。比如访问url下的目录，直接列出了目录下的文件列表，错误的报错信息包含了网站的信息。
 2、 工具挖掘，像爬虫之类的工具可以扫描到敏感文件路径，从而找到敏感数据。

防范措施

 1、 对系统处理、存储或传输的数据进行分类，根据分类进行访问控制。
 2、 对用户敏感信息的传输和存储进行加密
 3、 强化安全意识

7.缺少功能级的访问控制

原理

     大多数Web应用程序的功能在UI页面显示之前,会验证功能级别的访问权限。但是,应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证,攻击者能够伪造请求从而在未经适当授权时访问功能。
 比如：对于测试登录页面功能级访问控制是否缺失，需要测试
 a：合法用户是否能够正常登录，并且访问到登录之后的页面
 b：匿名或者攻击者等没有权限的用户是否会被拒绝登录，并且不能访问到需要登录之后才能访问到的页面。

测试方法

1、 保证合法授权用户可以访问成功 2、 限制非法未授权用户的访问

危害

很多系统的权限控制是通过页面灰化或隐藏URL实现的，没有在服务器端进行身份确认和权限验证，导致攻击者通过修改页面样式或获取隐藏URL，进而获取特权页面来对系统进行攻击，或者在匿名状态下对他人的页面进行攻击，从而获取用户数据或提升权限。 ​ 如果是发生在后台，攻击者能够访问到正常用户才能访问到的页面，将对所有用户的安全问题造成威胁。

防御措施

1、 设计严格的权限控制系统，对于每个请求和URL都要进行校验和权限确认，防止非法请求被执行 2、 对于每个功能的访问，都要有明确的角色授权，采用过滤器的方式校验每个请求的合法性 3、 实现Web访问的IP白名单列表，禁止不可信的IP访问Web系统

8.跨站请求伪造（CSRF）

原理

1、 用户输入账号信息请求登录A网站。 2、 A网站验证用户信息，通过验证后返回给用户一个cookie 3、 在未退出网站A之前，在同一浏览器中请求了黑客构造的恶意网站B 4、 B网站收到用户请求后返回攻击性代码，构造访问A网站的语句 5、 浏览器收到攻击性代码后，在用户不知情的情况下携带cookie信息请求了A网站。此时A网站不知道这是由B发起的。那么这时黑客就可以进行一下骚操作了。

条件

• 用户访问站点A并产生了cookie

• 用户没有退出A同时访问了B

分类

GET型

如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。 当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了。

POST型

在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。

CSRF漏洞挖掘

1、 抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞 2、 如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。 3、 利用工具进行CSRF检测。如：CSRFTESTER，CSRF REQUEST BUILDER等。

防御措施

1、 验证http referer中记录的请求来源地址是否是合法用户地址（即最开始登录的来源地址）。但这只能进行简单的防御，因为这个地址可以人为的篡改。 2、 重要功能点使用动态验证码进行CSRF防护 3、 通过token方式进行CSRF防护，在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击 a：在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。 b：在form表单中自动填入token字段，比如 <input type=hidden name="anti_csrf_token" value="$token" />。 c: 在HTTP请求中自动添加token。

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

原理

大多数的开发团队并不会把及时更新组件和库当成他们的工作重心，更不关心组件和库的版本，然而应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，可能导致严重的数据丢失或服务器接管。

防范

1.标识正在使用的所有组件和版本，包括所有依赖项 2.及时关注这些组件的安全信息并保证他们是最新的。 3.建立使用组件的安全策略，禁止使用未经安全评估的组件。 4.在适当情况下，对组件进行安全封装，精简不必要的功能，封装易受攻击部分

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

简介

重定向是服务端根据逻辑，发送一个状态码（通常为3xx），告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL。（重定向是在客户端完成的）

转发是在服务器内部将请求转发给另一个资源，把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,因为这个跳转过程是在服务器实现的，并不是在客户端实现的所以客户端并不知道这个跳转动作，所以它的地址栏还是原来的地址。（转发是在服务器端完成的）

• 重定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求，转发是服务器收到请求后为了完成响应跳转到一个新的地址。

• 重定向有两次请求，不共享数据，转发是有一次请求且共享数据。

• 重定向后地址栏会发生变化，转发不会。

• 重定向的地址可以是任意地址，转发的地址只能是当前应用类的某一个地址。

重定向的方式：

• 手工重定向

• 点击 href 链接来跳转到新页面

• 响应状态码重定向(location表示重定向后网页)

• 301 永久重定向(网站在响应头的location内)

• 302 临时重定向

• 服务器端重定向

  修改web服务器配置文件或脚本来实现重定向,

• meta refresh 利用HTTP的refresh标签或者响应头refresh属性来设置

• 客户端跳转 利用url参数重定向，控制不严可能会导致用户访问恶意网站

危害

在web应用中，重定向和转发可以使我们愉快的浏览网页，那么这个漏洞是怎么来的呢？重点就是没有对带有用户输入参数的目的url做验证。而这个时候攻击者就可以引导用户访问他们所要用户访问的站点。这个漏洞最常见的就是钓鱼网站的使用。 ​ 比如：http://www.baidu.com/sss.php?target=http://diaoyu.com 攻击者把这个钓鱼连接发给受害者，那么安全检测的软件就判断这个连接来自百度，是可信任的站点。但是受害者点击后则会跳转到钓鱼网站或者其他欺骗木马之类的站点等 ​ 此外还有获取信息，访问恶意网站，随意跳转，安装恶意软件等。

检测方式

1、 抓包工具抓包，抓到302的url，修改看能否正常跳转 2、 浏览代码，看代码中含有重定向和转发的内容，看目的url中是否包含用户输入的参数 3、 点击操作网站，观察在重定向之前用户输入的参数有没有出现在某一个URL或者很多URL中

预防

重定向外部网站需要验证是否在白名单,转发内部网站要验证是否有权限,有权限才转发。