常见Web漏洞整理

最新推荐文章于 2024-05-17 03:13:15 发布

Kevin_David_Mitnick

最新推荐文章于 2024-05-17 03:13:15 发布

阅读量758

点赞数

文章标签：安全 csrf xss web

本文链接：https://blog.csdn.net/TH_DL/article/details/107344620

版权

跨站脚本攻击（XSS）

XSS简介

XSS攻击：常指攻击者通过“HTML注入“篡改了网页，插入了恶意代码，从而在用户浏览网页时，控制用户浏览器的一种攻击方式。

反射型（非持久型XSS）

用户提交的数据中可以构造代码来执行，从而实现窃取用户信息等攻击。
即简单地把用户输入的数据“反射”给浏览器需要诱使用户“点击”一个恶意链接，才能攻击成功。

储存型

存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。

DOM型

通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

Dom型的XSS是一些有安全意识的开发者弄出来的。比如说接受参数会做一些过滤，把一些字符转义一下，但是转义之后依然会存在着XSS的情况，比如说下图中，我们上面输入的可以看到这行代码规律，把这个大括号、小括号以及双页号进行转移，按理说转移之后它应该不会再作为它的标签存在，不会存在XSS的代码。

DOM 节点是指在XML文档中的每个成分都是一个节点。整个文档就是一个文档节点，每个XML标签是一个元素节点。

DOM型和反射型的区别

反射型XSS：通过诱导用户点击，我们构造好的恶意payload才会触发的XSS。
反射型XSS的检测:我们在每次请求带payload的链接时页面应该是会带有特定的畸形数据的。
DOM型：通过修改页面的DOM节点形成的XSS。 DOM-based
XSS由于是通过js代码进行dom操作产生的XSS，所以在请求的响应中我们甚至不一定会得到相应的畸形数据。根本区别在我看来是输出点的不同。

payload:在计算机安全中，有效载荷是恶意软件（如蠕虫或病毒）的一部分，它们执行恶意操作：删除数据、发送垃圾邮件或加密数据。除了有效载荷之外，这种恶意软件通常还具有旨在简单地传播自身或避免检测的开销代码。

漏洞利用

通过XSS攻击，进行“cookie劫持”（可通过HttpOnly防御）
通过XSS攻击，构造GET与POST请求
XSS钓鱼
通过XSS攻击，识别用户浏览器
通过XSS攻击，识别用户安装的软件
通过XSS攻击，获取用户的真实IP地址（通常借助第三方软件完成）

XSS攻击平台

Attack API
BeEF
XSS-Proxy

XSS蠕虫的产生条件

正常情况下，一个是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生。不一定需要存储型XSS。不过一般来说，用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易发起XSS Worm。

典型代表：Samy Worm、百度空间蠕虫

XSS构造技巧

利用字符编码
绕过长度限制
使用标签
利用window.name构造

XSS的防御

输入检查（白名单）

输出检查

安全编码函数（在正确的地方使用正确的安全编码函数）

输入点检查：对用户输入的数据进行合法性检查，使用filter过滤敏感字符或对进行编码转义，针对特定类型数据进行格式检查。针对输入点的检查最好放在服务器端实现。

输出点检查：对变量输出到HTML页面中时，对输出内容进行编码转义，输出在HTML中时，对其进行HTMLEncode，如果输出在Javascript脚本中时，对其进行JavascriptEncode。

DOM型XSS的防御:

如果用户的输出点在

跨站请求伪造（CSRF）

CSRF攻击是攻击者利用用户的身份操作用户账户的一种攻击方式。是由于在关键操作执行时，没有对操作是否由用户自愿发起进行确认，所导致的。造成该漏洞的本质原因是：重要操作的所有参数都是可以被攻击者猜测到的。

漏洞利用

攻击者盗用了用户的身份，以用户的名义发送恶意请求。CSRF能够做的事情包括：以用户名义发送邮件，发消息，盗取用户的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。

CSRF的防御

验证码
验证Referer
添加token（不可预测性原则)

token和referer做横向对比，谁安全等级高？

token安全等级更高，因为并不是任何服务器都可以取得referer，如果从HTTPS跳到HTTP，也不会发送referer。并且FLASH一些版本中可以自定义referer。
但是token的话，要保证其足够随机且不可泄露。(不可预测性原则)

针对token，对token测试会注意哪方面内容，会对token的哪方面进行测试？

针对token的攻击：
一是对它本身的攻击，重放测试一次性、分析加密规则、校验方式是否正确等
二是结合信息泄露漏洞对它的获取，结合着发起组合攻击

注入攻击

注入攻击的本质：服务器(或Web应用程序)把用户输入的数据当作代码执行。违背了数据与代码分离的原则这里有两个关键条件：

用户能够控制输入
原本程序要执行的代码，拼接了用户输入的数据

SQL注入

如何判断注入

【最为经典的单引号判断法】： 在参数后面加上单引号,比如:http://xxx/abc.php?id=1'如果页面返回错误，则存在 Sql 注入。 原因是无论字符型还是整型都会因为单引号个数不匹配而报错。

【数字型判断】：当输入的参 x 为整型时，通常 abc.php 中 Sql 语句类型大致如下： select * from <表名> where id = x 这种类型可以使用经典的 and 1=1 和 and 1=2 来判断：Url 地址中输入 http://xxx/abc.php?id= x and 1=1 页面依旧运行正常，继续进行下一步。Url 地址中继续输入 http://xxx/abc.php?id= x and 1=2 页面运行错误，则说明此 Sql 注入为数字型注入。原因如下： 当输入 and 1=1时，后台执行 Sql 语句：select * from <表名> where id = x and 1=1 没有语法错误且逻辑判断为正确，所以返回正常。当输入 and 1=2时，后台执行 Sql 语句：select * from <表名> where id = x and 1=2没有语法错误但是逻辑判断为假，所以返回错误。 我们再使用假设法：如果这是字符型注入的话，我们输入以上语句之后应该出现如下情况：select * from <表名> where id = 'x and 1=1' select * from <表名> where id = 'x and 1=2' 查询语句将 and 语句全部转换为了字符串，并没有进行 and 的逻辑判断，所以不会出现以上结果，故假设是不成立的。

【字符型判断】：当输入的参 x 为字符型时，通常 abc.php 中 SQL 语句类型大致如下： select * from <表名> where id = 'x' 这种类型我们同样可以使用 and '1'='1 和 and '1'='2来判断：Url 地址中输入 http://xxx/abc.php?id= x' and '1'='1 页面运行正常，继续进行下一步。Url 地址中继续输入 http://xxx/abc.php?id= x' and '1'='2 页面运行错误，则说明此 Sql 注入为字符型注入。

盲注

盲注是在SQL注入攻击过程中，服务器关闭了错误回显，我们单纯通过服务器返回内容的变化来判断是否存在SQL注入和利用的方式。盲注的手段有两种：

一个是构造简单的条件语句通过页面的返回内容是否正确(boolean-based)，来验证是否存在注入。
一个是通过SQL语句处理时间的不同来判断是否存在注入(time-based)，在这里，可以用benchmark，sleep等造成延时效果的函数，也可以通过构造大笛卡儿积的联合查询表来达到延时的目的。RLIKE

数据库攻击技巧

构造简单的SQL语句进行注入获得信息
命令执行，利用“用户自定义函数”(UDF)来执行命令
攻击存储过程，如xp_cmdshell、sp_configure
编码问题(数据库，操作系统，Web应用所使用的字符集不统一)如：宽字节注入

宽字节注入产生原理以及根本原因

产生原理

在数据库使用了宽字符集（用多个字节来代表的字符称之为宽字符。）而WEB中没考虑这个问题的情况下，在WEB层，由于0XBF27是两个字符，在PHP中比如addslash和magic_quotes_gpc开启时，由于会对0x27单引号进行转义，因此0xbf27会变成0xbf5c27,而数据进入数据库中时，由于0XBF5C是一个另外的字符，因此\转义符号会被前面的bf带着"吃掉"，单引号由此逃逸出来可以用来闭合语句。

根本原因

character_set_client(客户端的字符集)和character_set_connection(连接层的字符集)不同,或转换函数如，iconv、mb_convert_encoding使用不当。

解决办法

统一数据库、Web应用、操作系统所使用的字符集，避免解析产生差异，最好都设置为UTF-8。
或对数据进行正确的转义，如mysql_real_escape_string+mysql_set_charset的使用。

SQL注入防御

使用预编译语句，绑定变量
使用安全的存储过程
检查数据类型
使用安全编码函数
使用安全的API
合理地分配数据库权限（最小权限原则）

API（Application Programming Interface，应用程序接口）是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问原码，或理解内部工作机制的细节。

XML注入

XML是一种常用的标记语言，通过标签对数据进行结构化表示。

XML 指可扩展标记语言（EXtensible Markup Language）。
XML 是一种很像HTML的标记语言。
XML 的设计宗旨是传输数据，而不是显示数据。
XML 标签没有被预定义。您需要自行定义标签。
XML 被设计为具有自我描述性。
XML 是 W3C 的推荐标准。
XML 被设计用来传输和存储数据，其焦点是数据的内容。
HTML 被设计用来显示数据，其焦点是数据的外观。

防御：对用户输入数据中包含的“语言本身的保留字符”进行转义

代码注入

代码注入与命令注入往往都是由一些不安全的函数或者方法引起的，如eval(),system()等

防御：禁用危险函数（可参考开发语言的官方文档）

CRLF注入

CRLF：回车（ASCII 13，\r）换行（ASCII 10，\n）常做不用语义之间的分隔符。因此通过“注入CRLF字符”可改变语义。

漏洞利用

log注入，修改日志信息
注入HTTP头，通过两次CRLF注入到HTTP Body，一次CRLF注入修改HTTP头。

防御

处理好CRLF这两个保留字符即可。

外部实体注入攻击（XXE）

XXE注入，即XML External Entity，XML外部实体注入。通过 XML 实体，”SYSTEM”关键词导致 XML 解析器可以从本地文件或者远程 URI 中读取数据。所以攻击者可以通过 XML 实体传递自己构造的恶意值，使处理程序解析它。当引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。

漏洞原理

既然XML可以从外部读取DTD文件，那我们就自然地想到了如果将路径换成另一个文件的路径，那么服务器在解析这个XML的时候就会把那个文件的内容赋值给SYSTEM前面的根元素中，只要我们在XML中让前面的根元素的内容显示出来，不就可以读取那个文件的内容了。这就造成了一个任意文件读取的漏洞。

漏洞利用

1.任意文件读取

2.探测sql盲注

3.探测内网地址

防御

使用开发语言提供的禁用外部实体的方法

服务器端请求伪造（SSRF）

SSRF是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统，也就是把目标网站当中间人）

SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

检测

SSRF漏洞的验证方法：

1）因为SSRF漏洞是让服务器发送请求的安全漏洞，所以我们就可以通过抓包分析发送的请求是否是由服务器发送的，从而来判断是否存在SSRF漏洞

2）在页面源码中查找访问的资源地址，如果该资源地址类型为 www.baidu.com/xxx.php?image=（地址）的就可能存在SSRF漏洞

3）直接返回的Banner、title、content等信息

SSRF漏洞的成因防御绕过

成因：模拟服务器对其他服务器资源进行请求，没有做合法性验证。
利用：构造恶意内网IP做探测，或者使用其余所支持的协议对其余服务进行攻击。

内外网的端口和服务扫描
主机本地敏感数据的读取
内外网主机应用程序漏洞的利用
内外网Web站点漏洞的利用
让服务端去访问相应的网址，收集内网信息，攻击内网应用程序
可以使用file、dict、gopher[11]、ftp协议进行请求访问相应的文件

防御：禁止跳转，限制协议，内外网限制，URL限制。

禁止跳转
过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
禁用不需要的协议，仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题
设置URL白名单或者限制内网IP（使用gethostbyname()判断是否为内网IP）
限制请求的端口为http常用的端口，比如 80、443、8080、8090

绕过：使用不同协议;针对IP:IP格式的绕过;针对URL:恶意URL增添其他字符，@之类的。301跳转+dns rebindding。

DNS重绑定DNS Rebinding攻击

在网页浏览过程中，用户在地址栏中输入包含域名的网址。浏览器通过DNS服务器将域名解析为IP地址，然后向对应的IP地址请求资源，最后展现给用户。而对于域名所有者，他可以设置域名所对应的IP地址。当用户第一次访问，解析域名获取一个IP地址；然后，域名持有者修改对应的IP地址；用户再次请求该域名，就会获取一个新的IP地址。对于浏览器来说，整个过程访问的都是同一域名，所以认为是安全的。这就造成了DNS
Rebinding攻击。

基于这个攻击原理，Kali
Linux提供了对应的工具Rebind。该工具可以实现对用户所在网络路由器进行攻击。当用户访问Rebind监听域名，Rebind会自动实施DNS
Rebinding攻击，通过用户的浏览器执行js脚本，建立socket连接。这样，Rebind可以像局域网内部用户一样，访问路由器，从而控制路由器。

文件上传漏洞

原理

文件上传是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。

常见的恶意上传文件类型

web脚本语言（服务器的Web容器解释并执行了用户上传的文件，导致代码执行）
病毒、木马文件
钓鱼图片、包含脚本的图片

常见的上传绕过方式

前端js验证：禁用js/burp改包
大小写
双重后缀名
过滤绕过 pphphp->php
%00字符截断

可利用漏洞

Apache文件解析问题（在Apache 1.x 2.x中，对文件名的解析是从后往前解析的）
IIS文件解析问题（IIS 6 “ ；”截断问题，.asp文件夹解析问题，PUT功能）
PHP CGI路径解析问题（Nginx配置fastcgi使用PHP时，存在文件类型解析问题）
利用上传文件钓鱼

防御

文件上传目录设置为不可执行
使用白名单判断文件上传类型（结合MIME type、后缀检查等方式）
用随机数改写文件名和文件路径

文件包含漏洞

文件包含

简单一句话，为了更好地使用代码的重用性，引入了文件包含函数，可以通过文件包含函数将文件包含进来，直接使用包含文件的代码。

文件包含可以包含任意文件，即便被包含的文件并不是与当前编程语言相关，甚至为图片，只要文件被包含，其内容会被包含文件包含，并以当前服务器脚本语言执行。文件包含漏洞属于“代码注入”。

文件包含漏洞成因

在包含文件时候，为了灵活包含文件，将被包含文件设置为变量，引入一段用户能控制的脚本或代码，并让服务器端执行。通过动态变量来引入需要包含的文件时，用户可以对变量的值可控而服务器端未对变量值进行合理地校验或者校验被绕过，这样就导致了文件包含漏洞。通常文件包含漏洞出现在PHP语言中。

常见导致文件包含的函数

PHP：include(), include_once(), require(), require_once(), fopen(), readfile(), …
JSP/Servlet：ava.io.File(), java.io.Fil-eReader(), …
ASP：include file, include virtual, …

本地文件包含漏洞（LFI）

当包含的文件在服务器本地时，就形成了本地文件包含。

本地文件包含的利用技巧

包含用户上传的文件
包含data:// 或 php://input等伪协议
包含Session文件
包含日志文件

漏洞利用

通过查看本地文件文件，可任意包含（＋本地地址），读取敏感文件。
结合文件上传，可包含上传的恶意代码并执行，从而拿到webshell。

远程文件包含漏洞

当包含的文件在远程服务器上时，就形成了远程文件包含。

需要php.ini中allow_url_include = on以及allow_url_fopen=on
所包含远程服务器的文件后缀不能与目标服务器语言相同。

漏洞利用

在远程服务器上上传恶意代码，通过远程文件包含执行恶意代码，从而拿到webshell

因为需要php.ini中allow_url_include =
on以及allow_url_fopen=on才可利用，一般这两个参数是处于关闭状态，如果拥有操作php.ini的权限，一般不需要通过远程文件包含获得webshell。故该利用没有实用价值