Web安全（白帽子讲）之第二篇

第二章：浏览器安全

2.1、同源策略

　　是一种约定，它是浏览器最核心也是最基本的安全功能。

　　web是构建在同源策略的基础之上，浏览器只是针对同源策略的一种实现

影响“源” 的因素有：host（域名或IP地址，如果是IP地址则看做一个根域名）、子域名、端口、协议

什么叫同源？

URL由协议、域名、端口和路径组成，如果两个URL的协议、域名和端口相同，则表示他们同源。相反，只要协议，域名，端口有任何一个的不同，就被当作是跨域。

同源策略  Same-Origin-Policy(SOP)

浏览器采用同源策略，禁止页面加载或执行与自身来源不同的域的任何脚本。换句话说浏览器禁止的是来自不同源的"document"或脚本，对当前"document"读取或设置某些属性。

情景：

比如一个恶意网站的页面通过iframe嵌入了银行的登录页面（二者不同源），如果没有同源限制，恶意网页上的javascript脚本就可以在用户登录银行的时候获取用户名和密码。

 

在浏览器中<script>、<img>、<iframe>、<link>等标签都可以跨域加载资源，而不受同源策略的限制。这些带“src”属性的标签每次加载时，实际上是由浏览器发起一次GET请求。不同于XMLHttpRequest的是，通过src属性加载的资源，浏览器限制了JavaScript的权限，使其不能读、写返回的内容。

注：XMLHttpRequest受到同源策略的约束，不能跨越访问资源。

2.2.跨域

跨域是指从一个域的网页去请求另一个域的资源。比如从http://www.baidu.com/ 页面去请求 http://www.google.com 的资源。

 

w3c委员会制定了XMLHttpRequest跨域访问标准。它需要通过目标域返回的HTTP头来授权是否允许跨域访问，因为HTTP头对于JavaScript来说一般无法控制的

注：这个跨域访问方案的安全基础就是信任“JavaScript无法控制该HTTP头”，如果此信任基础被打破，则方案也将不再安全。

 

 

挂马：在网页中插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式。

 

Sandbox（沙箱） ：目的一般是为了让不可信任的代码运行在一定环境中，限制不可信任的代码访问隔离区之外的资源。

 

2.3 恶意网址拦截的工作原理：

　　浏览器周期性地从服务器端获取一份最新的恶意网址黑名单，如用户上网时访问的网址存在于此黑名单汇总，浏览器就会弹出一个警告页面。

 

恶意网址分为两类：　

（1）挂马网站，通过浏览器漏洞执行shellcode植入木马；

（2）钓鱼类网站，通过模仿知名网站的相似页面来欺骗用户。

 

第三章：跨站脚本攻击（XSS）--前端安全

 

 3.1、XSS介绍

　　XSS（cross site scipt）跨站脚本攻击，为了和层叠样式CSS区别，所以在安全领域叫做“XSS”

　　　　这种攻击方式主要是在客户端（浏览器）中通过非法的JavaScript脚本来更改页面，是客户端脚本安全中的头号大敌。

 

 　　XSS攻击，通常是指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在客用户浏览网页时，控制用户浏览器的一种攻击。

　　 XSS的本质还是一种“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而混淆了原本的语义，产生了新的语义

　　XSS分类：　  
　　　　反射型：只是简单地把用户输入的数据“反射”给浏览器，也叫“非持久型XSS”
　　　　存储型：把用户输入的数据“存储”在服务器端，也叫“持久型XSS”
　　　　DOM Based XSS：通过修改页面的DOM节点形成的XSS

3.2 XSS攻击进阶

　　XSS payload实际就是JavaScript脚本（还可以是Flash或其他富客户端的脚本），所以任何JavaScript脚本能实现的功能，XSS payload都能做到。

 

 可以利用XSS payload来窃取Cookie。但”Cookie劫持”并非所有的时候都会有效，有的网站可能会在Set-Cookie时给关键的Cookie**植入HttpOnly标识；有的网站会把Cookie与客户端IP绑定**。

 

　　 Cookie中一般加密保存了当前用户的登录凭证。Cookie如果丢失，往往意味着用户的登录凭证丢失。即攻击者可以不通过密码，而直接登录进用户的账户。

 　　Cookie是能够让网站服务器把少量文本数据存储到客户端的硬盘、内存，或是从客户端的硬盘、内存读取数据的一种技术。可以记录你的用户ID、密码、停留的时间等信息。当前Web中，Cookie一般都是用户登录的凭证，浏览器发起的所有请求都会自动带上Cookie。 　　 

XSS Payload

　　用以完成各种具体功能的恶意脚本。一个常见的XSS Payload就是通过读取浏览器的Cookie对象，从而发起“Cookie劫持”攻击。XSS Payload还包括构造GET与POST请求、XSS钓鱼、识别用户浏览器、识别用户安装的软件、CSS History Hack、获取用户的真实IP地址。
 　　

XSS Worm

　　一般发生在用户之间发生交互行为的页面，存在存储型XSS，更容易发起攻击。

XSS漏洞利用：
窃取Cookie信息，造成会话劫持
构造GET和POST请求，如get执行删除操作，gost，构造form表单或者通过XMLHttpRequest
XSS钓鱼,利用JavaScript在页面上画一个伪造的登录框
识别用户的浏览器版本，通过UserAgent
识别用户安全的软件，classid，通过软件漏洞，进行攻击
识别用户访问过的网站； 利用CSS中的style的visited属性
获取用户真实的ip
XSS攻击平台：AttactAPI
XSS Worm ：存储型Xss发起

XSS构造技巧

　　（1）利用字符编码

　　　　要求数据库，web服务器，系统，使用相同的字符编码，一般为UTF-8
　　　　服务器使用GB2312编码，浏览器使用utf-8编码。导致后台的“\”会被构造的字符吃掉变为一个新的UTF字符，导致注释失效

　　（2）绕过长度限制：

　　　　a）利用事件来缩短所需的字节数

　　　　b）把XSS Payload写到别处，再通过简短的代码加载，location.hash就是常用的方式

　　　　c）利用住注释符绕过长度限制

　　（3）使用<base>标签

　　　　　　把本页面的所有相对路径，都附上base指向的恶意网址。然后在恶意网址的服务器中构造相应的路径。

　　（4）使用window.name实现跨域、跨页面传递数据。

 3.3、XSS防御

 

3.3.1、HttpOnly　

　　 由微软提出，并在IE6上实现

 　　httpOnly标签至今已经逐渐成为一个标准，浏览器禁止JS访问带有HttpOnly的Cookie，HttpOnly可以选择性的加载任何一个Cookie值上

 　　解决的是XSS后的Cookie劫持攻击，

　

　　服务器发送指示，要求set-Cookie中某一个cookie httpOnly。那么浏览器会设置所有的cookie。但是设置了httpOnly的cookie是不能被访问的。 
　　通过TRACE请求可以绕过这个，它的responseBody里面会返回cookie.

一个Cookie的使用过程
    Step1：浏览器向服务器发起请求，这是没有Cookie
    Step2：服务器返回时发送Set-Cookie头，向客户端浏览器写入Cookie
    Step3：在该Cookie到期前，浏览器访问该域下的所有页面，都将发送该Cookie
    HttpOnly是在Set-Cookie时标记的

不同语言中，Cookie添加HttpOnly的例子：

Java EE
response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

C#
HttpCookie cookie = new HttpCookie("myCookie");
cookie.HttpOnly = true;
Response.AppendCookie(cookie);

PHP
header("Set-Cookie: hidden=value; httpOnly");

PHP
setcookie("cookiename","value",NULL,NULL,NULL,NULL,TRUE)

3.2.2　　输入检查 （转义或过滤）

　　常见的web漏洞注入类问题，都要求攻击者构造一些特殊字符，这些特殊字符是正常用户用不到的，所以输入检查就有必要了

　　输入检查的逻辑，必须放在服务器端代码中实现，一般考虑到性能的要求是浏览器和服务器中双实现

 .白名单的思想，被用户白名单的检查，如邮件，电话等格式
 .检查用户输入数据中包含的特殊字符，如`“<” “>” “、”等
 .XSS Filter:比较智能的“输入检查”，可能匹配XSS特征。
    比如查找用户数据中是否包含了“<script>”、“javascript”等敏感字符
    XSS Filter在用户提交数据时获取变量，并进行检查；但此时用户数据并
    没有结合渲染页面的HTML代码，因此XSS Filter对于语境的理解并不完整

3.2.3  输出检查  （转义，使用编码方式）

　　一般来说，除了富文本的输出外，在变量输出到HTML页面时，可以采用编码或者转义的方式防御XSS

　　XSS攻击主要发生在MVC架构中的View层。

安全的编码函数

• HtmlEncode：针对HTML代码的编码方式
• JavascriptEncode:Jacascrpt的编码方式
• PHP-----htmlentitles()和htmlspecialchars()两个函数
• XMLEcode（其实现与HtmlEncode类似）；JSONEncode（与JavascriptEncode累次）

HtmlEncode

HtmlEncode是一种函数实现，他的作用是讲字符转换为HTMLEntities，对应的标准为ISO--
为对抗XSS，在HTMLEncode中要求至少转换一下字符
& -->;<–>;>–>;"–>;’–>;/ -->

Javascript

.JavaScript与htmlencode方式不同，他需要使用“\”对特使字符进行转义
.要求输出的变量必须在引号的内部
例如：var y = '"'+escapeJavascipt($evil) + '"'
攻击者想要逃逸出信号的范围，会有困难

 

3.2.4  正确的防御XSS

　　在不同的输出地方使用不同的编码方式。

 

3.2.5  处理富文本

• 使用输入检查的思路，使用白名单，避免使用黑名单
• 在过滤富文本时，“事件”应该被严格禁止；一些危险的标签被禁止，如<script> 、<iframe>、<base>、<form>等
• 只允许一些比较安全的标签如：<a > <img> <div>

3.2.6 防御DOM Based XSS

在button的onclick事件中，调用了test（）函数，将HTML代码写入DOM节点，最后导致了XSS的发生。test（）函数中获取用户输入的变量，
变量输出在Script脚本中，最后又被.innerHTML输出到HTML页面中
下面是javascript输出到HTML页面的必经之路：

• xxx.innerHTML=
• xxx.outerHTML=
• document.write()
• document.writeIn()

防御：

• 首先在变量输出到Scritp中时，应该执行一次JavascritpEncode
• 其次在.innerHTML输出到HTML中，分情况执行HTMLEncode或者JavascritpEncode

小节：

• 当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。
• 当恶意代码被作为某一标签的属性显示，通过用 “将属性截断来开辟新的属性或恶意方法：属性本身存在的 单引号和双引号都需要进行转码；对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。

 

 https://blog.csdn.net/u012861467/article/details/79530629

https://www.cnblogs.com/edisonchou/p/edc_web_security_foundation_notes.html