WEB常见安全漏洞讲解
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.2 各个业务账号只能访问自己业务的数据。这样即使某个漏洞被注入，也只是影响到该业务的数据，不会影响到其他业务的模块
TOP-2 失效的身份认证和会话管理
漏洞案例
案例 #1： 机票预订应用程序支持 URL重写， 把会话 ID放在URL里： http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV ?dest=Ha waii 该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给 他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将 会使用他的会话和信用卡。
3数据库权限做限制
3.1 不能对业务账号开 select information_schema 权限。因为一旦某个漏洞被成功注入，information_schema库暴露所有库， 所有表，字段的定义。给sql注入者提供了便利，，， 注入者不需要猜测表结构，就能轻松获取所有表的定义，进而轻松获取所有 表的数据
TOP-1 注入
如何识别SQL注入
数字型 单引号： http://xxx.com/xx.asp?id=1’ 逻辑真假：http://xxx.com/xx.asp?id=1 and 1=1 http://xxx.com/xx.asp?id=1 and 1=2 加减符号：http://xxx.com/xxx.asp?id=2-1 字符型 单引号： http://xxx.com/xx.asp?name=xx’ 逻辑真假：http://xxx.com/xx.asp?name=xx’ and ‘a’=‘a http://xxx.com/xx.asp?name=xx’ and ‘a’=‘b 加减符号：http://xxx.com/xxx.asp?name=pet’+’ter
TOP-6 敏感信息泄露
攻击案例 案例 #1： 一个应用程序加密存储在数据库的信用卡信息，以防止信用卡信息暴 露给最终用户 。 但是， 数据库设置为对信用卡表列的询进行自动解密， 这就使 得 S QL注入漏洞能够获得所有信用卡信息的明文。 该系统应该被设置为前端应 用程序使用公钥对信用卡信息加密， 后端应用程序只能使用私钥解密。
TOP-1 注入 防范
1 参数校验：
传递的参数做校验，如果不合法，直接拒绝请求。 1.1 如果是数字类型，判断是否为数字，如果不是，直接拒绝请求 1.2 如果有格式的类型（比如 日期，email，电话，身份证号码等等），判断是非符合格式，如果不符合格式，拒绝请求。 1.3 如果是字符串类型，没有特殊的格式，需要对字符串长度做校验，如果长度大于数据库该字段的定义长度，直接拒绝请求。 比如 姓名，数据库定义的事 varchar(12),如果输入超过12个字符，直接拒绝请求
TOP-1 注入
什么是SQL注入？
通过把SQL命令插入用户提交的数据中，改变代码原有SQL语句的语义，从而达到 控制 服务器执行恶意的SQL命令。
可以插入SQL语句并执行
TOP-1 注入
漏洞案例
应用程序在下面存在漏洞的 SQL语句的构造中使用不可信数据： String query = " SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";
2 使用 PrepareStatement。PrepareStament可以有效防御sql注入攻击。
PrepareStatement原理是：mysql执行树会根据预设的参数做转义，可以把注入的sql当作一个参数执行，而不会当作语句执行 php 应用， 可以使用PrepareStatement 替代 Statement写法。
TOP-7 功能级访问控制缺失
未登录用户 (游客)
有漏洞
http://example.com/app/getappInfo
普通用户 功能页面
UI JS
有漏洞
http://example.com/app/admin_getappInfo
已登录用户 （普通用户）
管理员 功能页面
TOP-8 跨站请求伪造（CSRF）
TOP-4 不安全的直接对象引用
已登录的用户 （ID：123）
http://www.test.com/user？id=123
ID:123的个人信息
有漏洞！
http://www.test.com/user？id=125
ID:125的个人信息
TOP-5 安全配置错误
漏洞案例 注意这些问题：
案例 #1： 应用程序服务器管理员控制台自动安全后没有删除 。而默认账户也没有改变。 1. 是否有软件没有被及时更新？这包括操作系统、 Web /应用服务器、数据库管理系统、 攻击者在你的服务器上发现了标准的管理员页面，通过默认密码登录，从而接管了你的服 应用程序和其它所有的代码库文件。 务器。 2. 是否使用或安装了不必要的功能（例如，端口、服务、网页、帐户、权限） ？ 3. 默认帐户的密码是否仍然可用或没有更改？ 案例 #2： 目录列表在你的服务器上未被禁用。攻击者发现只需列出目录，她就可以找到 4. 你的错误处理设置是否防止堆栈跟踪和其他含有大量信息的错误消息被泄露 ? 你服务器上的任意文件。攻击者找到并下载所有已编译的 Java类，她通过反编译获得了 5. 你的开发框架（比如：Struts、Spring、ASP. NET）和库文件中的安全设置是否理解 所有你的自定义代码。然后，她在你的应用程序中找到一个访问控制的严重漏洞。 正确并配置恰当？
案例 #2： 应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点 击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。 案例 #3： 内部或外部攻击者进入系统的密码数据库.存储在数据库中的用户密码没有被加密, 所有用户的密码都被攻击者获得。
TOP-2 失效的身份认证和会话管理
1. 用户身份验证凭证没有使用哈希或加密保护。 2. 认证凭证可猜测， 或者能够通过薄弱的的帐户管理功能（例如账 户创建、 密码修改、 密码恢复 , 弱会话 ID）重写。 3. 会话 ID暴露在 URL里 （例如 , URL重写） 。 4. 会话 ID容易受到会话固定（ sessionfixaPon） 的攻击。？？？ 5. 会话 ID没有超时限制， 或者用户会话或身份验证令牌特别是单点 登录令牌在用户注销时没有失效。 6. 成功注册后 ,会话 ID没有轮转。 7. 密码、 会话 ID和其他认证凭据使用未加密连接传输。
TOP-8 跨站请求伪造（CSRF）
请求的参数可预知 诱惑让已登录用户访问
构造的请求自动提交 攻击者在构造这个请求 链接 or 页面 以用户的身份向 服务器发送请求 浏览器的cookie机制
TOP-10 未验证的重定向和转发
验证应用程序是否有未验证的重定向或转发的最好的方法是： 1. 审查所有使用重定向或转发的代码。 每一次使用， 都应该验证目标 URL是否被包含在任何参数值中。 如果是， 且目标URL并不在经过验证 的白名单中， 那么就是存在漏洞的。 2. 此外， 抓取网站内容查看是否能产生重定向（ HTTP响应代码从300 到307， 通常是302） 。 检查重定向之前提供的参数是否是目标URL或 其一部分。 如果是的话，更改URL的目的地， 并观察网站是否重定向到 新的目标。 3. 如果没有代码， 检查所有的参数以辨别它们是否看起来像一个重定向 或转发目的地网址的一部分， 对那些看起来像的参数进行测试。
WEB常见安全漏洞讲解
Ana
应用程序安全风险
攻击者 攻击向量 安全漏洞 安全控制 技术影响 业务影响
影响 资产 功能 攻击 漏洞 漏洞 控制 影响 资产
攻击
攻击
漏洞
漏洞
控制 控制
影响
OWASP TOP 10 漏洞
1
2 3 4 5
注入
6
7 8
敏感信息泄露
功能级访问控制缺失 跨站请求伪造
失效的身份认证和会话管理
案例 #3： 应用服务器配置允许堆栈跟踪返回给用户， 这样就暴露了潜在的漏洞。 攻击 者热衷于收集错误消息里提供的额外信息。
案例 #4： 应用服务器自带的示例应用程序没有删除。 该示例应用有已知安全漏洞， 攻 击者可以利用这些漏洞破坏您的服务器。
TOP-6 敏感信息泄露
首先你需要确认的是哪些数据是敏感数据而需要被加密。例如： 密码、 信用卡、 医疗记录、 个人信息应该被加密。对于这些数据， 要确保： 1. 当这些数据被长期存储的时候， 无论存储在哪里， 它们是否都被加密， 特别 是对这些数据的备份？ 2. 无论内部数据还是外部数据， 传输时是否是明文传输？在互联网中传输明文数 据是非常危险的。 3. 是否还在使用任何旧的或脆弱的加密算法？ 4. 加密密钥的生成是否是脆弱的， 或者缺少恰当的密钥管理或缺少密钥回转？ 5. 当浏览器接收或发送敏感数据时， 是否有浏览器安全
TOP-3 跨站脚本（XSS）
什么是跨站脚本攻击？
往Web页面里插入恶意html/js代码
插入
当用户浏览该web页面时
攻击 浏览
插入HTML/JS代码并执行
嵌入Web页面里面的html代码会被执行
执行
从而达到攻击用户的特殊目的
TOP-3 跨站脚本（XSS） 防范
最好的办法是根据数据将要置于的HTML上下文（包括主体、 属性、 JavaScript、 CSS或URL） 对所有的不可信数据进行恰当的转义 （ escape） 。 更多关于数据转义技术的信息见OWASP XSS PrevenPon Cheat Sheet 。
提示错误 返回正确 返回错误 返回与id=1相等
提示错误 返回正确 返回错误 返回与name=petter相同
搜索型 单引号： http://xxx.com/xx.asp?keyword=1’ 提示错误 逻辑真假：http://xxx.com/xx.asp?keyword=1%’ and ‘%’=‘ 返回查询1的内容 http://xxx.com/xx.asp?keyword=1%’ and ‘%1’=‘ 无内容返回或不是1的内容
谢谢！
ห้องสมุดไป่ตู้
攻击者在浏览器中将“ id ”参数的值修改成 10000’ or ’1’=’1。 如： http://example.com/app/accountView?id= 10000’ or ’1’=’1 这样查询语句的意义就变成了从 accounts表中返回所有的记录。
‘10000 ‘; SELECT * FROM accounts WHERE custID= SELECT * FROM accounts WHERE custID= ‘ ‘;
案例 #2： 一个网站上所有需要身份验证的网页都没有使用 S S L。 攻击者只需 监控网络数据流（比如一个开放的无线网络或其社区的有线网络） ， 并窃取一 个已验证的受害者的会话 cooki e。 然后， 攻击者利用这个 cooki e执行重放攻 击并接管用户的会话从而访问用户的隐私数据
案例 #3： 密码数据库使用 u n s al ted的哈希算法去存储每个人的密码。 一个文 件上传漏洞使黑客能够获取密码文件。所有这些 u n s al ted
跨站脚本 不安全的直接对象引用 安全配置错误
9
使用含有已知漏洞的组件
10 未验证的重定向和转发
TOP-1 注入
原因：应用程序缺少对输入进行安全性设 计。 方式：攻击者将一些包含指令的数据发送 给解释器，欺骗解释器执行计划外的命令。
危害：读取或篡改数据库的信息，甚至能 够获得服务器的包括管理员的权限。
TOP-2 失效的身份认证和会话管理
漏洞案例
案例 #1： 机票预订应用程序支持 URL重写， 把会话 ID放在URL里： http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV ?dest=Ha waii 该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给 他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将 会使用他的会话和信用卡。
3数据库权限做限制
3.1 不能对业务账号开 select information_schema 权限。因为一旦某个漏洞被成功注入，information_schema库暴露所有库， 所有表，字段的定义。给sql注入者提供了便利，，， 注入者不需要猜测表结构，就能轻松获取所有表的定义，进而轻松获取所有 表的数据
TOP-1 注入
如何识别SQL注入
数字型 单引号： http://xxx.com/xx.asp?id=1’ 逻辑真假：http://xxx.com/xx.asp?id=1 and 1=1 http://xxx.com/xx.asp?id=1 and 1=2 加减符号：http://xxx.com/xxx.asp?id=2-1 字符型 单引号： http://xxx.com/xx.asp?name=xx’ 逻辑真假：http://xxx.com/xx.asp?name=xx’ and ‘a’=‘a http://xxx.com/xx.asp?name=xx’ and ‘a’=‘b 加减符号：http://xxx.com/xxx.asp?name=pet’+’ter
TOP-6 敏感信息泄露
攻击案例 案例 #1： 一个应用程序加密存储在数据库的信用卡信息，以防止信用卡信息暴 露给最终用户 。 但是， 数据库设置为对信用卡表列的询进行自动解密， 这就使 得 S QL注入漏洞能够获得所有信用卡信息的明文。 该系统应该被设置为前端应 用程序使用公钥对信用卡信息加密， 后端应用程序只能使用私钥解密。
TOP-1 注入 防范
1 参数校验：
传递的参数做校验，如果不合法，直接拒绝请求。 1.1 如果是数字类型，判断是否为数字，如果不是，直接拒绝请求 1.2 如果有格式的类型（比如 日期，email，电话，身份证号码等等），判断是非符合格式，如果不符合格式，拒绝请求。 1.3 如果是字符串类型，没有特殊的格式，需要对字符串长度做校验，如果长度大于数据库该字段的定义长度，直接拒绝请求。 比如 姓名，数据库定义的事 varchar(12),如果输入超过12个字符，直接拒绝请求
TOP-1 注入
什么是SQL注入？
通过把SQL命令插入用户提交的数据中，改变代码原有SQL语句的语义，从而达到 控制 服务器执行恶意的SQL命令。
可以插入SQL语句并执行
TOP-1 注入
漏洞案例
应用程序在下面存在漏洞的 SQL语句的构造中使用不可信数据： String query = " SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";
2 使用 PrepareStatement。PrepareStament可以有效防御sql注入攻击。
PrepareStatement原理是：mysql执行树会根据预设的参数做转义，可以把注入的sql当作一个参数执行，而不会当作语句执行 php 应用， 可以使用PrepareStatement 替代 Statement写法。
TOP-7 功能级访问控制缺失
未登录用户 (游客)
有漏洞
http://example.com/app/getappInfo
普通用户 功能页面
UI JS
有漏洞
http://example.com/app/admin_getappInfo
已登录用户 （普通用户）
管理员 功能页面
TOP-8 跨站请求伪造（CSRF）
TOP-4 不安全的直接对象引用
已登录的用户 （ID：123）
http://www.test.com/user？id=123
ID:123的个人信息
有漏洞！
http://www.test.com/user？id=125
ID:125的个人信息
TOP-5 安全配置错误
漏洞案例 注意这些问题：
案例 #1： 应用程序服务器管理员控制台自动安全后没有删除 。而默认账户也没有改变。 1. 是否有软件没有被及时更新？这包括操作系统、 Web /应用服务器、数据库管理系统、 攻击者在你的服务器上发现了标准的管理员页面，通过默认密码登录，从而接管了你的服 应用程序和其它所有的代码库文件。 务器。 2. 是否使用或安装了不必要的功能（例如，端口、服务、网页、帐户、权限） ？ 3. 默认帐户的密码是否仍然可用或没有更改？ 案例 #2： 目录列表在你的服务器上未被禁用。攻击者发现只需列出目录，她就可以找到 4. 你的错误处理设置是否防止堆栈跟踪和其他含有大量信息的错误消息被泄露 ? 你服务器上的任意文件。攻击者找到并下载所有已编译的 Java类，她通过反编译获得了 5. 你的开发框架（比如：Struts、Spring、ASP. NET）和库文件中的安全设置是否理解 所有你的自定义代码。然后，她在你的应用程序中找到一个访问控制的严重漏洞。 正确并配置恰当？
案例 #2： 应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点 击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。 案例 #3： 内部或外部攻击者进入系统的密码数据库.存储在数据库中的用户密码没有被加密, 所有用户的密码都被攻击者获得。
TOP-2 失效的身份认证和会话管理
1. 用户身份验证凭证没有使用哈希或加密保护。 2. 认证凭证可猜测， 或者能够通过薄弱的的帐户管理功能（例如账 户创建、 密码修改、 密码恢复 , 弱会话 ID）重写。 3. 会话 ID暴露在 URL里 （例如 , URL重写） 。 4. 会话 ID容易受到会话固定（ sessionfixaPon） 的攻击。？？？ 5. 会话 ID没有超时限制， 或者用户会话或身份验证令牌特别是单点 登录令牌在用户注销时没有失效。 6. 成功注册后 ,会话 ID没有轮转。 7. 密码、 会话 ID和其他认证凭据使用未加密连接传输。
TOP-8 跨站请求伪造（CSRF）
请求的参数可预知 诱惑让已登录用户访问
构造的请求自动提交 攻击者在构造这个请求 链接 or 页面 以用户的身份向 服务器发送请求 浏览器的cookie机制
TOP-10 未验证的重定向和转发
验证应用程序是否有未验证的重定向或转发的最好的方法是： 1. 审查所有使用重定向或转发的代码。 每一次使用， 都应该验证目标 URL是否被包含在任何参数值中。 如果是， 且目标URL并不在经过验证 的白名单中， 那么就是存在漏洞的。 2. 此外， 抓取网站内容查看是否能产生重定向（ HTTP响应代码从300 到307， 通常是302） 。 检查重定向之前提供的参数是否是目标URL或 其一部分。 如果是的话，更改URL的目的地， 并观察网站是否重定向到 新的目标。 3. 如果没有代码， 检查所有的参数以辨别它们是否看起来像一个重定向 或转发目的地网址的一部分， 对那些看起来像的参数进行测试。
WEB常见安全漏洞讲解
Ana
应用程序安全风险
攻击者 攻击向量 安全漏洞 安全控制 技术影响 业务影响
影响 资产 功能 攻击 漏洞 漏洞 控制 影响 资产
攻击
攻击
漏洞
漏洞
控制 控制
影响
OWASP TOP 10 漏洞
1
2 3 4 5
注入
6
7 8
敏感信息泄露
功能级访问控制缺失 跨站请求伪造
失效的身份认证和会话管理
案例 #3： 应用服务器配置允许堆栈跟踪返回给用户， 这样就暴露了潜在的漏洞。 攻击 者热衷于收集错误消息里提供的额外信息。
案例 #4： 应用服务器自带的示例应用程序没有删除。 该示例应用有已知安全漏洞， 攻 击者可以利用这些漏洞破坏您的服务器。
TOP-6 敏感信息泄露
首先你需要确认的是哪些数据是敏感数据而需要被加密。例如： 密码、 信用卡、 医疗记录、 个人信息应该被加密。对于这些数据， 要确保： 1. 当这些数据被长期存储的时候， 无论存储在哪里， 它们是否都被加密， 特别 是对这些数据的备份？ 2. 无论内部数据还是外部数据， 传输时是否是明文传输？在互联网中传输明文数 据是非常危险的。 3. 是否还在使用任何旧的或脆弱的加密算法？ 4. 加密密钥的生成是否是脆弱的， 或者缺少恰当的密钥管理或缺少密钥回转？ 5. 当浏览器接收或发送敏感数据时， 是否有浏览器安全
TOP-3 跨站脚本（XSS）
什么是跨站脚本攻击？
往Web页面里插入恶意html/js代码
插入
当用户浏览该web页面时
攻击 浏览
插入HTML/JS代码并执行
嵌入Web页面里面的html代码会被执行
执行
从而达到攻击用户的特殊目的
TOP-3 跨站脚本（XSS） 防范
最好的办法是根据数据将要置于的HTML上下文（包括主体、 属性、 JavaScript、 CSS或URL） 对所有的不可信数据进行恰当的转义 （ escape） 。 更多关于数据转义技术的信息见OWASP XSS PrevenPon Cheat Sheet 。
提示错误 返回正确 返回错误 返回与id=1相等
提示错误 返回正确 返回错误 返回与name=petter相同
搜索型 单引号： http://xxx.com/xx.asp?keyword=1’ 提示错误 逻辑真假：http://xxx.com/xx.asp?keyword=1%’ and ‘%’=‘ 返回查询1的内容 http://xxx.com/xx.asp?keyword=1%’ and ‘%1’=‘ 无内容返回或不是1的内容
谢谢！
ห้องสมุดไป่ตู้
攻击者在浏览器中将“ id ”参数的值修改成 10000’ or ’1’=’1。 如： http://example.com/app/accountView?id= 10000’ or ’1’=’1 这样查询语句的意义就变成了从 accounts表中返回所有的记录。
‘10000 ‘; SELECT * FROM accounts WHERE custID= SELECT * FROM accounts WHERE custID= ‘ ‘;
案例 #2： 一个网站上所有需要身份验证的网页都没有使用 S S L。 攻击者只需 监控网络数据流（比如一个开放的无线网络或其社区的有线网络） ， 并窃取一 个已验证的受害者的会话 cooki e。 然后， 攻击者利用这个 cooki e执行重放攻 击并接管用户的会话从而访问用户的隐私数据
案例 #3： 密码数据库使用 u n s al ted的哈希算法去存储每个人的密码。 一个文 件上传漏洞使黑客能够获取密码文件。所有这些 u n s al ted
跨站脚本 不安全的直接对象引用 安全配置错误
9
使用含有已知漏洞的组件
10 未验证的重定向和转发
TOP-1 注入
原因：应用程序缺少对输入进行安全性设 计。 方式：攻击者将一些包含指令的数据发送 给解释器，欺骗解释器执行计划外的命令。
危害：读取或篡改数据库的信息，甚至能 够获得服务器的包括管理员的权限。