web安全性测试

别妄想泡我
783次浏览
2021年02月13日 08:02
最佳经验
本文由作者推荐

-

2021年2月13日发(作者：家族企业管理)


.


WEB


安全性测试



第一章：预备知识：



1.1 SQL


语句基础



1.2 HTML


语言



HTML


（


HyperTextMark-upLanguage

）


即


超文本标记语言


，

< p>
是


WWW


的描述语言。


h tml


是在


sgml


定义下的一个描述性语言，或可说


html


是


sgml


的一个应用程式，


html


不是程式语言，


它只是标示语言。



实例：





< br>


这个表单会把电子发送到


W3School


。



：







电邮：







容：









发送




重置







表单提交中


Get


和

< br>Post


方式的区别有


5


点




1. get


是从服务器上获取数据，


post


是向服务器传送数据。



2.


get


是把 参数数据队列加到提交表单的


ACTION


属性所指的


URL


中，值和表单各个字段一


一对应，在


URL


中可以看到。


post


是通过


HTTP post


机制，将表单各个字段与其容放置在


HTML HEA DER


一起传送到


ACTION


属性所 指的


URL


地址。用户看不到这个过程。



3.


对于


get


方式，


服务器端用


tring


获取变量的值，


对于


post


方式，< /p>


服务


器端用



获取 提交的数据。



.


.


4. get


传送的数据量较小，不能大于

2KB


。


post


传送的数据量较 大，一般被默认为不受限


制。但理论上，


IIS4


中最大量为


80KB


，


II S5


中为


100KB


。



5. get


安全性非常低，


post


安全性较高。




Get


服务器上获取数据



在


URL


中可以看到



区别



tring

获


取


变量的值



数据量较小



安全性非常低




Post


向服务器传送数据



用户看不到这个过程




获取提交的数


据



数据量较大



安全性高



1.3 HTTP


协议



HTTP


（


HyperTextTransferProtocol


） 是超文本传输协议的缩写，它用于传送


WWW


方式的数


据。


HTTP


协议采用了请求

< br>/


响应模型。客户端向服务器发送一个请求，请求头包含请求的方


法、


URI


、协议版本、以及包含请求修饰符、客户信 息和容的类似于


MIME


的消息结构。服务

器以一个状态行作为响应，


相应的容包括消息协议的版本，


成功或者错误编码加上包含服务


器信息、实体元信息以及可能的实体容。




HTTP


协议的主要特点可概括如下：



1.


支持客户


/


服务器模式。



2.


简单快速：


客户向服务器请求服务时，


只需传送请求方法和路径。


请求方法常


用的有


GET


、


HEAD


、


POST

< br>。每种方法规定了客户与服务器联系的类型不同。



由于


HTTP


协议简单，使得


HTTP


服务器的程序规模小，因而通信速度很快。



3.


灵活：


HTTP


允许传输任意类 型的数据对象。正在传输的类型由


Content- Type


加以标记。



4.

< p>
无连接：


无连接的含义是限制每次连接只处理一个请求。

< br>服务器处理完客户的


请求，并收到客户的应答后，即断开连接。采用这种方式可以 节省传输时间。



5.


无状态：


HTTP


协议是无状态协议。无状态是指协议对于事务处理没有记忆能


力。


缺少状态意味着如果后续处理需要前面的信息，

< p>
则它必须重传，


这样可能导


.


.


致每次连接传送的数据量增大。


另 一方面，


在服务器不需要先前信息时它的应答


就较快。



6.


基于


TCP


传输





1.4 Cookie


和


Session


< /p>


是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，可以用来在某

< p>
个


WEB


站点会话间持久的保持数据。

< p>


n


（会话）其实指的就是


访问者从到达某个特定主页到离开为止的那段时间。



Ses sion


其实是利用


Cookie


进行 信息处理的，当用户首先进行了请求后，服务端就在用户


浏览器上创建了一个

< p>
Cookie


，当这个


Session

< p>
结束时，其实就是意味着这个


Cookie


就过期


了。



注：为这个用户创建的


Cookie


的名称是


aspsessioni d


。这个


Cookie


的唯一目的就是 为每


一个用户提供不同的身份认证。




和


session


的共同之处在于：< /p>


cookie


和


session


都是用来跟踪浏览器用户身份的


会话方式。




和


session

< br>的区别是：


cookie


数据保存在客户端


，


session


数据保存


在服务器端


。




简单的说，当你登录一个的时候，







1.5


常见


WEB


安全漏洞

< br>


Injection(SQL


注入


)


-site scritping(XSS):(


跨站点脚本攻 击


)



Header Injection(


标头注入


)


ory Traversal(


目录遍历


)


d error messages(


错误信息


)



第二章：


SQL Injectio n(


SQL


注入


)

古老安全性漏洞



2.1


什么是


SQL


注入



.


.


所谓


SQL


注入，


就是通过把


SQL


命令插入到


Web


表单递交或输入域名或页面 请求的查询字符


串，


最终达到欺骗服务器执行恶意的

< p>
SQL


命令，


比如先前的很多影视泄露

< p>
VIP


会员密码大多


就是通过

WEB


表单递交查询字符暴出的，这类表单特别容易受到


S QL


注入式攻击．



2.2


如何进行


SQL


注入



1


首先找到带有参数传递的


URL< /p>


页面


,


如



搜索页面


,


登录页面


,


提交评论页面等等


.


< p>
对于未明显标识在


URL


中传递参数的

< p>
,


可以通过查看


HTML


源代码中的



标签


来辨别是否还有参数传 递


.


在



和



的标签中间的每一个参数传递都


有可能被利用


.
















当你找不到有输入行 为的页面时


,


可以尝试找一些带有某些参数的特殊的

< p>
URL,


如


HTTP://DOMAIN/?ID =10


2


其


次


,


在


URL

参数或表单中加入某些特殊的


SQL


语句或


SQL


片断


,


如在登录页


面的


URL


中输入


HTTP://DOMAIN /?USERNAME=HI' OR 1=1


—



注


1


：根据实际情况


,SQL


注入请求可 以使用以下语句


:



' or 1=1- -





or 1=1- -



' or 'a'='a





') or ('a'='a



Select * from user where username=


’


' or 1=1


’


and password=


’’


;


< /p>


注


2


：为什么是


OR


，



以及


',


――是特殊的字符呢？



例子：在 登录时进行身份验证时，通常使用如下语句来进行验证：


sql=select * from user where


username='username' and pwd='password'



如



输入


duck/?username=


admin' or 1='1


&pwd=


11


，


SQL


语句会变成以下：


s ql=select * from user where username='


admin' or 1='1


' and password='


11


'



'


与


admin

前面的


'


组成了一个查询条件


,< /p>


即


username='admin',


接下来的语句将按下一个查询条件来执行


.



接



下来是


O R


查询条件


,OR


是一个逻辑运



算符，在判断多个条件的时候，只要一个成立，则等式就成立，


.


.


后面的


A ND


就不再时行判断了，也就是



说我 们绕过了密码验证，我们只用用户名就可以登录


.



如



输入


du ck/?username=


admin'--


&pwd=


11


，


SQL


语< /p>



句会变成以下


sql=select *


from user where name='


admin' --


' and pasword='


1


1',



'


与


admin

前面的


'


组成了一个查



询条件


,


即


usern ame='admin',


接下来的语句将按下一个查询条件来执行



接下来是


查询条件


,


“


--


”


是忽略或注释


,


上



述通过连接符注释掉后面的密码验证


(


注


:


对


ACCESS


数据


库


无



效


).



最后


,


验证是否能入侵成功或是出错的信息是否包含关于数据库服务 器



的相关信息


;

如果



能说明存在


SQL


安



全漏洞


.



试 想


,


如果存在


SQL

< br>注入的危险


,


对于有经验的恶意用户还可能猜出数据库表 和表结构


,


并对


数据库表进行增



删



改的操

< p>


作


,


这样造成的后果是 非常严重的


.



第三章：

< p>
XSS(


跨站点脚本攻击


)



3.1


什么是


CSS


XSS


又叫


CSS (Cross Site Script)


，


跨站


脚 本攻击。它指的是恶意攻击者往


Web


页


面里插入恶意


html


代码，当用户浏览该页之时，嵌入其中


Web


里面的


html


代码会被


执行，从而达到恶意攻击用户的特殊目的。


X SS


属于被动式的攻击，因为其被动且不


好利用，所以许多人常 忽略其危害性。




新浪微博


XSS


受攻击事件





2011


年


6


月


28


日晚，


新浪微博出现了一次比较大的


XSS


攻击事件。


大量用户自动发送诸如：


“郭美美事件的一些未注意到的细节”，

< p>
“建党大业中穿帮的地方”，


“让女人心动的


10 0


句诗


歌”，“


3D

< br>肉团团高清普通话版种子”，“这是传说中的神仙眷侣啊”，“惊爆


!

< p>
冰冰艳照真流


出了”等等微博和私信，并自动关注一位名为


hellosamy


的用户。





事件的经过线索如下：





20:14


，开始有大量带


V


的认证用户中招转发蠕虫





20:30


，某中的病毒页面无法访问





20:32


，新浪微博中


hellosamy


用户无法访问





21:02


，新浪漏洞修补完毕



3.2


如何进行


XSS


测试



首先


,


找到带有参数传递的


URL,


如


登录页面


,


搜索页面

< p>
,


提交评论


,


发表留言< /p>



页面等等。其


次


,


在页面参数中输入如下语句


(


如< /p>


:


Javascr


ī

pt,VB scr


ī


pt, HTML,ActiveX, Flash


)


来进行测


试，如下代码：



ī

pt>alert()


ī


pt>


最后


,


当用户浏览



时便会弹出一个警告框，容显示的是浏览者当前的


cookie


串


,


这就说明该存


在


XSS


漏洞。


试想如果我们注入的不是 以上这个简单的测试代码，


而是一段经常精心设计的恶意


脚本， 当用户浏览此帖时，


cookie


信息就可能成功的被



攻击者获取。此时浏览者的就很容易被


攻击者 掌控了。



.

-


-


-


-


-


-


-


-