Web渗透测试攻略 [二]
HTTP头部
HTTP请求中包含很多的头部信息.很明显，你可以控制所有的头部信息,但是如果你把头部值设置错了什么的，很有可能这个请求就废了，服务端根本就不理你改的请求.大多数程序只用到几个常用的头部：
· Referer
含义：确认客户端是从哪一个链接跳到这儿来的
· Cookie
含义：接受客户端发送来的cookies
· User-Agent
含义：用来确认客户端用的是什么浏览器
· X-Forwarded-For
含义：得到客户端的ip地址(这个不是得到ip地址最好的方法，因为这是可以被伪造的)
其他的HTTP头部被服务端用到很多,服务端处理这些头部的时候可能存在安全隐患.但是，在web服务端发现bug比在web程序中发现bug要难的多.
有一个非常重要的头部是”Host”.Host头部主要被web服务器用来确认你想访问的是哪个网站.比如说，在一个服务器上搭建了好几个网站（提供虚拟主机服务）,几个网站的对外ip都是一样的.当你访问其中的一个网站时,虽然几个网站的ip都是一样的，但是服务器会看host这个字段值，这样它会知道你想要访问哪个网站了，就会返回这个网站的内容给你.如果你把Host字段的值改成ip地址或者一个无效的主机名,你有可能会得到别的网站返回的内容.
当你发送一个请求时，服务端会返回http响应.比如下面的响应:
响应中那个状态码非常重要.返回的状态码位于响应的第一行.客户端会根据响应码来处理响应.
下面的状态码是很常见的.
200 OK:服务器成功处理请求了
302 Found:重定向
401 Unauthorized:访问受限了
404 Not Found:请求的资源没找到
500 Internal Server Error:服务器处理请求的时候出错了
有一些状态码就很生僻了，比如418:I’m a teapot.
在状态码后面就是HTTP头了.返回的HTTP头会影响浏览器显示网页的方式.在上面示例的响应中,头部包含了下面的信息:
· Date
含义：日期
· Sever
含义：头部透露了一些关于服务器的信息，这个就是apache服务器,版本2.2.16
· X-Powered-By
含义：头部透露了更多的信息.
· Content-Length
含义：头部说明了响应的大小.
· Content-type
含义：头部告诉浏览器返回的是什么东西.如果这个值是text/html,浏览器会渲染响应.如果是text/plain,浏览器不会渲染.
· content
含义：部分就是返回的信息，可以是HTML网页,一些图片.当浏览器接收到一个HTML网页时，它会解析它并且自动接受一些其他的文件如:
Javascript文件
CSS文件
图片
…
HTTPs
HTTPs只是基于SSL的HTTP.SSL会确保客户端:
它和正确的服务器在交互:认证连接是安全的:加密.
SSL存在很多版本,其中一些版本被认为很弱（SSLv1和SSLv2）.
SSL也可以用来确认客户端的身份.客户端有个证书，这个证书确保了只有拥有有效证书的客户端才能和服务器通信.
这种方法常被用在安全性要求较高的系统中.然而，保存证书确实一个令人头痛的事情.
监听HTTP请求
有3种方法来监听HTTP请求:
· 用Wireshark或者tcpdump这类工具直接监听网络
· 在浏览器上查看.大多数浏览器都有可以允许用户查看发送和接受数据包的插件.
· 在浏览器和服务器中设置一个代理
三种方法有利有弊.使用哪一种主要取决于连接是否用了SSL和用户是否想修改请求.
产生HTTP请求
有好几种方法产生请求
.由于HTTP是一个基于文本的协议，你可以使用telnet或者netcat这些工具来构造请求
.也可以编程实现发送HTTP数据.用socket很容易实现在网络上读写数据.更方便的是，很多
语言都有HTTP库，用这些库我们会很容易构造和发送请求，也很轻松就能获得响应.
.当然，最简单的就是用浏览器来发送请求了.
用浏览器明显最便捷.但是，其他的方法更有益于你连接HTTP请求的细节.
用telnet发送请求
也可以用netcat
$ echo "GET / HTTP/1.1\r\nHost: vulnerable\r\n\r\n" | nc vulnerable 80
数据编码
代码vs数据
大多数的安全问题发生在攻击者可以操做上传的数据，并且应用程序会把这些数据当作代码执行.
比如xss和SQL注入.
URL编码
有一些字符在HTTP中需要特殊对待:
比如说url中的?,&,=号都有它自己的意思.不过对于大多数攻击来说，这些字符是必须的.为了保证这些字符能被理解成是值而不是请求的分隔符号;我们应该对这些字符进行编码.最简单的编码方式就是%后面跟上字符的十六进制值.为了得到一个字符的十六进制值，我们应该了解下ascii码表.下表可以看到字符和对应URL中编码的值:
Character URL encoded value
想要得到完整的ASCII码表，在大多数的linux系统上可以使用man ascii命令得到，或者google吧.
两次编码
有时候，被检测的系统会解码两次.例如，服务端解码后，应用程序解码第二次.这样的话，我们应该编码两次我们想要发送的字符.
例如,如果想要对等号=编码两次，第一次它被编码成%3d,第二次它就被编码成%253d了.服务端接收到%253d以后，会把它解码成%3d，然后应用程序会把%3d解码成=号.两次编码有时也可以用来bypass一些过滤.
HTML编码
和URL编码一样,一些HTML环境中的字符也有特殊的含义，所以如果要把他们当作普通的值用，也要对它们编码.
Character HTML encoded value
比如=可以编码成=,也可以编码成=.(注意有;分号)
Cookies和sessions
服务端会用一个HTTP头:Set-Cookie来初始化Cookie.浏览器接受到这个头部后，就会自动地把cookie
发送回服务端，并且以后的每次请求中都会用cookie头部带上这个cookie.
Set-Cookie头包含几个可选域:
· expiration date
过期时间:告诉浏览器什么时候该删除这个cookie.
· Domain域:
告诉浏览器cookie应该被发送到哪个主机或者子域名下,子域可以读取父域的cookie.
· Path路径:
告诉浏览器cookie应该发送到哪个路径下,只有目标路径下的js代码才能读到这个cookie.
安全标志
Path和Domain字段多数情况下是为了安全性.Cookie有两个安全相关的标志
· httpOnly
可以阻止js代码读写cookie.这样在跨站脚本中document.cookie就没作用了，盗不了cookie.
· secure
带有这个标志的cookie只能在HTTPS层面安全传输.如果请求是HTTP的，这个cookie就不会被传送.session机制采用的是在服务器端保持状态的方案。而cookie机制采用的是在客户端保持状态的方案。
当客户端访问到一个程序时，程序要为客户创建一个session，在创建这个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识（session id），如果已包含一个session id则说明之前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
· Rack::Session::Cookie
在基于Rack程序中是默认使用的(大多数的Ruby程序都会用到Rack).它提供了一种不同的会话方法.用户虽然能接收到session的信息,但是这些信息是加密了的.这样的话，用户就不能修改session中的信息了(但是一旦解码出来，又能访问了).
在PHP中，默认情况下每一个sessions会存放在一个文件中，并且没有加密.(在Debian系统中位置在/var/lib/php5).如果你有权限访问这些文件，你就可以读取
到别人的session信息了.举个例子，加入你的session id是o8d7lr4p16d9gec7ofkdbnhm93，你会看到一个名字sess_o8d7lr4p16d9gec7ofkdbnhm93的文件，这个文件就包含了session中的信息.
HTTP认证
HTTP也提供方法来认证用户.协议中有三种可用的方法:
· Basic Authencation
用户名和密码用base64编码了，并且用了Authencation头部:
Digest Authencation
服务端发送一个–(独一无二的信息),客户端返回一个–(hash加密信息，其中包含用户的密码).这种方法确保了发送给服务器的密码是加密的.
· NTLM authencation
这种方法主要用在微软系统中，并且和Digest方法很像.
Web服务
想调用远程方法，用HTTP发送请求到服务是个不错的方法,基本上就是发送命令到服务端然后得到一个返回的响应.发送的东西可以是:
· HTTP请求
· XML消息
· 基于JSON的消息
远程的命令可以被服务端接受:
· 基于URL
· 基于HTTP头部(例如SOAPAction头部)
测试web服务和测试一般的web应用程序差不多，只不过浏览器不能跟服务端交互而已.如果你有一个请求的样本，你可以用工具或者自己用脚本语言来根据这个请求来fuzz和攻击服务端的代码.
web应用程序安全
客户端安全
一个普遍错误的做法是程序员在客户端进行安全检查，例如javascript中，验证一个手机号码是否有效.
一开始，用户会输入一个手机号码
JS代码会检查这个值
这个手机号码值貌似是有效的
这个值就会被发送到服务端
如果这个值无效，浏览器就不会发送这个这个请求
js代码会检查这个值
并且说明了这个值是错的
请求将被发送到服务器。
这种方式的检查是低能的，很容易就被绕过所以不能被用为安全检查机制。但是，通过限制发往服务器请求的数量，这种检查方式能减轻服务器的负担。如果每个发往服务器的请求都是正确的，错误的请求不会被发送到服务器，这样就相当于减轻了服务器的负担。
绕过客户端方面的检查
要绕过客户端这一侧检查，你需要架设一个像Burp Suite那样的代理服务器。当你运行了代理服务器之后，你还要设置下让你的浏览器将所有请求都转发到这个代理服务器（根据你的浏览器和操作系统来调节下 浏览器的设置或者环境变量）。之后你就可以看到所有浏览器发出的请求，并且有能力拦截和修改请求数据。
当你架设好这个代理服务器以后，你就有能力拦截浏览器发出的请求。
然后你可以修改它：
服务器会响应你修改过的请求：
在浏览器填写正确的值，就可以成功提交表单。但是，代理服务器拦截到这一请求，就能通过修改这个数值来达到攻击web应用程序的目的。
服务器端
应用程序的安全是在服务器这一侧履行的。所有的收到的信息都不应受信任；数据本身和数据格式都应该被考虑为带有恶意的输入。不要指望输入的参数是一连串的； 它可以是混杂或者是阵列的。不要指望输入的参数是整型；他可以是字符串。甚至连当前服务器的主机名（由host头提供）也能是恶意输入。不要信任任何输入数据，并确保你已经再次检查了所有的输入数据。如果你编写了一个安全性脆弱的应用程序，那很有可能被一些人找到一些问题。不要寄希望于别人找不到问题，如 果你编写了一个安全性脆弱的东西总会有人找到漏洞所在。
HTTP请求中包含很多的头部信息.很明显，你可以控制所有的头部信息,但是如果你把头部值设置错了什么的，很有可能这个请求就废了，服务端根本就不理你改的请求.大多数程序只用到几个常用的头部：
· Referer
含义：确认客户端是从哪一个链接跳到这儿来的
· Cookie
含义：接受客户端发送来的cookies
· User-Agent
含义：用来确认客户端用的是什么浏览器
· X-Forwarded-For
含义：得到客户端的ip地址(这个不是得到ip地址最好的方法，因为这是可以被伪造的)
其他的HTTP头部被服务端用到很多,服务端处理这些头部的时候可能存在安全隐患.但是，在web服务端发现bug比在web程序中发现bug要难的多.
有一个非常重要的头部是”Host”.Host头部主要被web服务器用来确认你想访问的是哪个网站.比如说，在一个服务器上搭建了好几个网站（提供虚拟主机服务）,几个网站的对外ip都是一样的.当你访问其中的一个网站时,虽然几个网站的ip都是一样的，但是服务器会看host这个字段值，这样它会知道你想要访问哪个网站了，就会返回这个网站的内容给你.如果你把Host字段的值改成ip地址或者一个无效的主机名,你有可能会得到别的网站返回的内容.
当你发送一个请求时，服务端会返回http响应.比如下面的响应:
HTTP/1.1 200 OK Date: Sun, 03 Mar 2013 10:56:20 GMT Server: Apache/2.2.16 (Debian) X-Powered-By: PHP/5.3.3-7+squeeze14 Content-Length: 6988 Content-Type: text/html <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>PentesterLab » Web for Pentester</title> <meta name="viewport" content="width=device-width, initialscale=1.0"> <meta name="description" content="Web For Pentester"> <meta name="author" content="Louis Nyffeneggerlouis@pentesterlab.com">
响应中那个状态码非常重要.返回的状态码位于响应的第一行.客户端会根据响应码来处理响应.
下面的状态码是很常见的.
200 OK:服务器成功处理请求了
302 Found:重定向
401 Unauthorized:访问受限了
404 Not Found:请求的资源没找到
500 Internal Server Error:服务器处理请求的时候出错了
有一些状态码就很生僻了，比如418:I’m a teapot.
在状态码后面就是HTTP头了.返回的HTTP头会影响浏览器显示网页的方式.在上面示例的响应中,头部包含了下面的信息:
· Date
含义：日期
· Sever
含义：头部透露了一些关于服务器的信息，这个就是apache服务器,版本2.2.16
· X-Powered-By
含义：头部透露了更多的信息.
· Content-Length
含义：头部说明了响应的大小.
· Content-type
含义：头部告诉浏览器返回的是什么东西.如果这个值是text/html,浏览器会渲染响应.如果是text/plain,浏览器不会渲染.
· content
含义：部分就是返回的信息，可以是HTML网页,一些图片.当浏览器接收到一个HTML网页时，它会解析它并且自动接受一些其他的文件如:
Javascript文件
CSS文件
图片
…
HTTPs
HTTPs只是基于SSL的HTTP.SSL会确保客户端:
它和正确的服务器在交互:认证连接是安全的:加密.
SSL存在很多版本,其中一些版本被认为很弱（SSLv1和SSLv2）.
SSL也可以用来确认客户端的身份.客户端有个证书，这个证书确保了只有拥有有效证书的客户端才能和服务器通信.
这种方法常被用在安全性要求较高的系统中.然而，保存证书确实一个令人头痛的事情.
监听HTTP请求
有3种方法来监听HTTP请求:
· 用Wireshark或者tcpdump这类工具直接监听网络
· 在浏览器上查看.大多数浏览器都有可以允许用户查看发送和接受数据包的插件.
· 在浏览器和服务器中设置一个代理
三种方法有利有弊.使用哪一种主要取决于连接是否用了SSL和用户是否想修改请求.
产生HTTP请求
有好几种方法产生请求
.由于HTTP是一个基于文本的协议，你可以使用telnet或者netcat这些工具来构造请求
.也可以编程实现发送HTTP数据.用socket很容易实现在网络上读写数据.更方便的是，很多
语言都有HTTP库，用这些库我们会很容易构造和发送请求，也很轻松就能获得响应.
.当然，最简单的就是用浏览器来发送请求了.
用浏览器明显最便捷.但是，其他的方法更有益于你连接HTTP请求的细节.
用telnet发送请求
$ telnet vulnerable 80 GET / HTTP/1.1 Host: vulnerable
也可以用netcat
$ echo "GET / HTTP/1.1\r\nHost: vulnerable\r\n\r\n" | nc vulnerable 80
数据编码
代码vs数据
大多数的安全问题发生在攻击者可以操做上传的数据，并且应用程序会把这些数据当作代码执行.
比如xss和SQL注入.
URL编码
有一些字符在HTTP中需要特殊对待:
比如说url中的?,&,=号都有它自己的意思.不过对于大多数攻击来说，这些字符是必须的.为了保证这些字符能被理解成是值而不是请求的分隔符号;我们应该对这些字符进行编码.最简单的编码方式就是%后面跟上字符的十六进制值.为了得到一个字符的十六进制值，我们应该了解下ascii码表.下表可以看到字符和对应URL中编码的值:
Character URL encoded value
\r %0d \n %0a %20 or `+` ? %3f & %26 = %3d ; %3b # %23 % %25
想要得到完整的ASCII码表，在大多数的linux系统上可以使用man ascii命令得到，或者google吧.
两次编码
有时候，被检测的系统会解码两次.例如，服务端解码后，应用程序解码第二次.这样的话，我们应该编码两次我们想要发送的字符.
例如,如果想要对等号=编码两次，第一次它被编码成%3d,第二次它就被编码成%253d了.服务端接收到%253d以后，会把它解码成%3d，然后应用程序会把%3d解码成=号.两次编码有时也可以用来bypass一些过滤.
HTML编码
和URL编码一样,一些HTML环境中的字符也有特殊的含义，所以如果要把他们当作普通的值用，也要对它们编码.
Character HTML encoded value
\r %0d \n %0a %20 or `+` ? %3f & %26 = %3d ; %3b # %23 % %25任何字符都可以用十进制或者十六进制编码.
比如=可以编码成=,也可以编码成=.(注意有;分号)
Cookies和sessions
服务端会用一个HTTP头:Set-Cookie来初始化Cookie.浏览器接受到这个头部后，就会自动地把cookie
发送回服务端，并且以后的每次请求中都会用cookie头部带上这个cookie.
Set-Cookie头包含几个可选域:
· expiration date
过期时间:告诉浏览器什么时候该删除这个cookie.
· Domain域:
告诉浏览器cookie应该被发送到哪个主机或者子域名下,子域可以读取父域的cookie.
· Path路径:
告诉浏览器cookie应该发送到哪个路径下,只有目标路径下的js代码才能读到这个cookie.
安全标志
Path和Domain字段多数情况下是为了安全性.Cookie有两个安全相关的标志
· httpOnly
可以阻止js代码读写cookie.这样在跨站脚本中document.cookie就没作用了，盗不了cookie.
· secure
带有这个标志的cookie只能在HTTPS层面安全传输.如果请求是HTTP的，这个cookie就不会被传送.session机制采用的是在服务器端保持状态的方案。而cookie机制采用的是在客户端保持状态的方案。
当客户端访问到一个程序时，程序要为客户创建一个session，在创建这个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识（session id），如果已包含一个session id则说明之前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
· Rack::Session::Cookie
在基于Rack程序中是默认使用的(大多数的Ruby程序都会用到Rack).它提供了一种不同的会话方法.用户虽然能接收到session的信息,但是这些信息是加密了的.这样的话，用户就不能修改session中的信息了(但是一旦解码出来，又能访问了).
在PHP中，默认情况下每一个sessions会存放在一个文件中，并且没有加密.(在Debian系统中位置在/var/lib/php5).如果你有权限访问这些文件，你就可以读取
到别人的session信息了.举个例子，加入你的session id是o8d7lr4p16d9gec7ofkdbnhm93，你会看到一个名字sess_o8d7lr4p16d9gec7ofkdbnhm93的文件，这个文件就包含了session中的信息.
| # cat /var/lib/php5/sess_o8d7lr4p16d9gec7ofkdbnhm93pentesterlab|s:12:"pentesterlab"; |
HTTP也提供方法来认证用户.协议中有三种可用的方法:
· Basic Authencation
用户名和密码用base64编码了，并且用了Authencation头部:
| Authorization: basic YWRtaW46YWRtaW4K. |
服务端发送一个–(独一无二的信息),客户端返回一个–(hash加密信息，其中包含用户的密码).这种方法确保了发送给服务器的密码是加密的.
· NTLM authencation
这种方法主要用在微软系统中，并且和Digest方法很像.
Web服务
想调用远程方法，用HTTP发送请求到服务是个不错的方法,基本上就是发送命令到服务端然后得到一个返回的响应.发送的东西可以是:
· HTTP请求
· XML消息
· 基于JSON的消息
远程的命令可以被服务端接受:
· 基于URL
· 基于HTTP头部(例如SOAPAction头部)
测试web服务和测试一般的web应用程序差不多，只不过浏览器不能跟服务端交互而已.如果你有一个请求的样本，你可以用工具或者自己用脚本语言来根据这个请求来fuzz和攻击服务端的代码.
web应用程序安全
客户端安全
一个普遍错误的做法是程序员在客户端进行安全检查，例如javascript中，验证一个手机号码是否有效.
一开始，用户会输入一个手机号码
JS代码会检查这个值
这个手机号码值貌似是有效的
这个值就会被发送到服务端
如果这个值无效，浏览器就不会发送这个这个请求
js代码会检查这个值
并且说明了这个值是错的
请求将被发送到服务器。
这种方式的检查是低能的，很容易就被绕过所以不能被用为安全检查机制。但是，通过限制发往服务器请求的数量，这种检查方式能减轻服务器的负担。如果每个发往服务器的请求都是正确的，错误的请求不会被发送到服务器，这样就相当于减轻了服务器的负担。
绕过客户端方面的检查
要绕过客户端这一侧检查，你需要架设一个像Burp Suite那样的代理服务器。当你运行了代理服务器之后，你还要设置下让你的浏览器将所有请求都转发到这个代理服务器（根据你的浏览器和操作系统来调节下 浏览器的设置或者环境变量）。之后你就可以看到所有浏览器发出的请求，并且有能力拦截和修改请求数据。
当你架设好这个代理服务器以后，你就有能力拦截浏览器发出的请求。
然后你可以修改它：
服务器会响应你修改过的请求：
在浏览器填写正确的值，就可以成功提交表单。但是，代理服务器拦截到这一请求，就能通过修改这个数值来达到攻击web应用程序的目的。
服务器端
应用程序的安全是在服务器这一侧履行的。所有的收到的信息都不应受信任；数据本身和数据格式都应该被考虑为带有恶意的输入。不要指望输入的参数是一连串的； 它可以是混杂或者是阵列的。不要指望输入的参数是整型；他可以是字符串。甚至连当前服务器的主机名（由host头提供）也能是恶意输入。不要信任任何输入数据，并确保你已经再次检查了所有的输入数据。如果你编写了一个安全性脆弱的应用程序，那很有可能被一些人找到一些问题。不要寄希望于别人找不到问题，如 果你编写了一个安全性脆弱的东西总会有人找到漏洞所在。
- 上一篇：Web渗透测试攻略 [三]
- 下一篇：Web渗透测试攻略 [一]
相关文章
图文推荐
- 文章
- 推荐
- 热门新闻