Web安全常识

Domain

1. 同源策略

同domain（或ip）,同端口，同协议视为同一个域，一个域内的脚本仅仅具有本域内的权限，可以理解为本域脚本只能读写本域内的资源，而无法访问其它域的资源。这种安全限制称为同源策略。
这里要记住不遵循同源策略的标签：

2. 同源策略，那些东西是同源可以获取到的

Document：每个载入浏览器的 HTML 文档都会成为 Document 对象。Document 对象使我们可以从脚本中对 HTML 页面中的所有元素进行访问
Cookie：Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器
LocalStorage：HTML5 提供了两种在客户端存储数据的新方法：localStorage
IndexDB：HTML5的支持的本地存储实际上变成了Web Storage（Local Storage和Session Storage）与IndexedDB

3. 如果子域名和顶级域名不同源，在哪里可以设置使其同源

如果一级域名相同，二级域名不同，浏览器可以通过设置document.domain共享 Cookie。
跨域问题，当然前置条件是我们在WEB服务器或者服务端脚本中设置ACCESS-CONTROL-ALLOW-ORIGIN头部，如果设置了这些头部并允许某些域名跨域访问，则浏览器就会跳过同源策略的限制返回对应的内容。
Ajax实现跨域资源的访问： 在服务器响应客户端的时候，带上Access-Control-Allow-Origin头信息。

4. 如何设置可以跨域请求数据？jsonp是做什么的？

Ajax实现跨域资源的访问： 在服务器响应客户端的时候，带上Access-Control-Allow-Origin头信息。
Jsonp：利用

5. CSP是什么？如何设置CSP？

内容安全策略（Content Security Policy，简称CSP）是一种以可信白名单作机制，来限制网站中是否可以包含某来源内容。是一个附加的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本攻击 (XSS) 和数据注入等攻击。
CSP 可以由两种方式指定：HTTP Header 和 HTML。HTTP 是在 HTTP 由增加 Header 来指定，而 HTML 级别则由 Meta 标签指定。
CSP 有两类：Content-Security-Policy 和 Content-Security-Policy-Report-Only
通过header指定，HTTP header :
“Content-Security-Policy:” 策略
“Content-Security-Policy-Report-Only:” 策略
通过Meta 标签指定

6. 如何判断sql注入，有哪些方法？

 整型参数的判断

当输入的参数YY为整型时，通常abc.asp中SQL语句原貌大致如下：
select * from 表名 where 字段=YY，所以可以用以下步骤测试SQL注入是否存在。
（1）HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp运行异常；
（2）HTTP://xxx.xxx.xxx/abc.asp?p=YY’(附加一个单引号)，此时abc.ASP中的SQL语句变成了select * from 表名 where 字段=YY’，abc.asp运行异常；
（3）HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp运行正常，而且与HTTP://xxx.xxx.xxx/abc.asp?p=YY运行结果相同；
如果这三个方面全部满足，abc.asp中一定存在SQL注入漏洞！

 字符串型参数的判断

当输入的参数YY为字符串时，通常abc.asp中SQL语句原貌大致如下：
select * from 表名 where 字段=’YY’，所以可以用以下步骤测试SQL注入是否存在。
（1）HTTP://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1’=’2′, abc.asp运行异常；
（2）HTTP://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1’=’1′, abc.asp运行正常，而且与HTTP://xxx.xxx.xxx/abc.asp?p=YY运行结果相同；
（3）HTTP://xxx.xxx.xxx/abc.asp?p=YY’(附加一个单引号)，此时abc.ASP中的SQL语句变成了select * from 表名 where 字段=YY’，abc.asp运行异常；
如果这三个方面全部满足，abc.asp中一定存在SQL注入漏洞！

有安全意识的ASP程序员会过滤掉单引号等字符，以防止SQL注入

7. 宽字符注入的原理？如何利用宽字符注入漏洞

宽字节注入源于程序员设置MySQL连接时错误配置为：set character_set_client=gbk，这样配置会引发编码转换从而导致的注入漏洞。
http://www.freebuf.com/articles/web/31537.html
id=1%aa%27 union%20select%201,2,concat(name,0x23,pass)%20from%20userInfo%23
%27是单引号，
我们这里的宽字节注入是利用mysql的一个特性，mysql在使用GBK编码的时候，会认为两个字符是一个汉字（前一个ascii码要大于128，才到汉字的范围）。如果我们输入%df’
当单引号前面会加一个反斜杠转义单引号时，%df和反斜杠会被mysql解析成汉字，从而后面的单引号确逃匿了出来

8. CRLF注入的原理

CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。

9. XSS攻击的发生场景？如何防御

XSS又称CSS，全称Cross SiteScript，跨站脚本攻击，是Web程序中常见的漏洞。它指的是恶意攻击者往Web 页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web 里面的html 代码会被执行，从而达到恶意用户的特殊目的。既然是将数据给注入到代码里面变成可执行代码
这种漏洞(XSS)通常用于发动cookie窃取、恶意软件传播(蠕虫攻击),会话劫持,恶意重定向。在这种攻击中,攻击者将恶意JavaScript代码注入到网站页面中,这样”受害”者的浏览器就会执行攻击者编写的恶意脚本。

4. XSS攻击的种类

对XSS的分类没有明确的标准，但业界普遍将XSS攻击分为三类。反射型XSS(non-persistent XSS), 存储型XSS(persistent XSS), DOM Based XSS
4.1 非持久性跨站点脚本攻击

非持久性XSS也称为反射型跨站漏洞。它是最常见的类型的XSS。漏洞产生的原因是攻击者注入的数据反映在响应中。如果你看了我们上面所示的例子,第一个例子是一个非持久的XSS攻击。一个典型的非持久性XSS包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)。

4.2 持久的跨站点脚本攻击

持久型跨站点脚本也称为存储跨站点脚本。它一般发生在XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。每当用户打开浏览器,脚本执行。在上面的示例中,第二个例子就展示了一个持久的XSS攻击。持久的XSS相比非持久性XSS攻击危害性更大,因为每当用户打开页面，查看内容时脚本将自动执行。谷歌的orkut曾经就遭受到XSS。

4.3 基于dom的跨站点脚本攻击

基于DOM的XSS有时也称为type0 XSS。当用户能够通过交互修改浏览器页面中的DOM(Document Object Model)并显示在浏览器上时，就有可能产生这种漏洞，从效果上来说它也是反射型XSS。
通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

防御手段：
（1）设置Cookie的属性为HttpOnly
（2）检查输入，过滤掉特殊字符
（3）输出检查，对输出数据进行安全编码，使用编码和转义方式来防御XSS，比如HtmlEncode、JavascriptEncode等
（4）代码和数据的合理分离

10. CSRF漏洞的本质是什么?

攻击者已将代码植入到受害者浏览器访问的页面的前提下，以受害者用户的身份向服务器发起请求，从而能实现对用户数据的CURD操作
CSRF(跨站点请求伪造)，就是攻击者诱使用户访问了一个页面，以该用户身份在第三方站点里执行相关操作。
比如：登陆了sohu博客后，只需要请求这个url，就能够吧编号为“156713012”的博客文章删除
http://blog.sohu.com/manage/entry.do?m=delete&id=156713012
攻击者首先在自己的域构造一个页面：
http://www.a.com/csrf.html
内容为：

攻击者诱使目标用户访问时，就自动请求了删除的url，回过头看帖子已经被删除。可以看到，CSRF攻击的关键是绕过用户伪造请求进行攻击。

10. 防御CSRF都有哪些方法

CSRF漏洞防御主要可以从三个层面进行，即服务端的防御、用户端的防御和安全设备的防御。

服务端的防御

验证HTTP Referer字段：根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL（本例中，通常是以bank. test域名开头的地址）。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。

验证码：最简洁而有效的防御方式。CSRF攻击的过程往往是用户不知情的情况下构造了网络请求。而验证码，则强制必须与应用交互。但不是所有的操作都加上验证码，因此使用场景有限

**在请求地址中添加token并验证：**CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。