Web高级 网站安全

1. SQL注入

虽然如今SQL注入发生的状况总的来讲愈来愈少,仍是提二句。关于什么是SQL注入你们都知道就很少说了。

1.1 原理

咱们在作前端页面的时候,少不了会又各类输入框,而后经过GET或者POST发送至后端。
那么若是后端在处理时直接使用SQL拼接的话就会产生问题。

//好比提交地址以下
//http://mysite/search?name='SQL'
在后端生成SQL语句为
var paramName = 'SQL'//从URL获取
var sqlQuery = "select * from table1 where name='"+paramName+"'"
//生成的结果为 - select * from table1 where name='SQL'
//若是咱们在URL中带过来的参数是 SQL or 1=1
//生成的结果则为 - select * from table1 where name='SQL' or 1=1
//那么学过SQL都知道咱们还能够在后面再添加语句以获取额外的数据

1.2 防范手段

1. 经过正则表达校验用户输入
   不实用,不论是在客户端仍是服务端作验证,都不能100%保证过滤全部状况.
   还有一个缺点就是会对正常数据输入形成必定影响。
2. 使用存储过程
   不实用,无论哪一个项目都不可能全局使用存储过程。
   
3. 参数化SQL语句
   较为常见
   如: SqlCommand.Parameters.Add("@name", SqlDbType.string).Value = "SQL";
   原理概述：数据库有一套执行计划重用原理,SQL语句的语句体会被预编译为执行计划,而参数会被隔离和辨识为独立部分。那么对于不符合预期的参数值或类型就不会获得正确执行。
4. 语言框架携带的对象->SQL转换机制
   较为常见，如Hibernate、Entity Framework 的LINQ

2. XSS

2.1 类型

• 反射型
  数据流向：浏览器 -> 后端 -> 浏览器
  如何产生：前端进行GET形式的数据提交至后端,由后端处理并将处理结果反馈到前端,前端将结果插入DOM。
  漏洞：A将一段带有特殊参数的连接发送给B，如http://ASite/pageA?param=,在服务端并未进行特殊处理的状况下,返回参数中的字符串到A。
  那么A将为加载从BSite的hack.js。则B站点能够窃取到A用户的cookie等信息。
  
• 存储型
  数据流向：浏览器 -> 后端 -> 存储 -> 后端 -> 浏览器
  如何产生：前端提交的数据并未进行特殊处理,就进行持久化存储,并将持久化存储的结果又展现给其余用户。
  漏洞：好比A在cnblog发表了一篇新的文章,他在该文章中嵌入了标签,那么全部访问过该文章的人就会被窃取到cookie等信息。

• DOM型
  数据流向：浏览器 -> 浏览器
  如何产生：前端使用脚本直接获取URL参数并插入到DOM中,全程没有服务端参与
  漏洞：A将一段带有特殊参数的连接发送给B，如http://ASite/pageA?param=,前端脚本会直接获取参数并插入DOM中,则B会加载B站点的hack.js，与反射型不一样的是这里不须要后端的参与.

  2.2 防护手段

1. Content Security Policy (CSP)
   CSP 的实质就是白名单制度，服务端明确告诉客户端，哪些外部资源能够加载和执行，等同于提供白名单。它的实现和执行所有由浏览器完成，开发者只需提供配置。CSP 大大加强了网页的安全性。攻击者即便发现了漏洞，也无法注入脚本。

• 如何启用：
  经过HTTP协议头Content-Security-Policy或meta标签来指定白名单
• 限制类型
  js,css,img,media,font,plugin,frame,workerjs,manifest,http connect等
• 违反处理X-XSS-Protection头
  禁止该页面加载
  或，上报违反行为
  注:如今不少代理网关或CDN会在页面中插入广告(经过劫持或内容替换等)或其余东西,若是采用禁止页面加载会影响终端用户的体验。对这种流氓行为怎么处理之后的文章会有提到。

3. CSRF

3.1 例子

1. 用户C访问正常网站A时进行登陆，浏览器保存A的cookie
2. 用户C再访问攻击网站B，网站B上有某个隐藏的连接或者图片标签会自动请求网站A的URL地址,例如表单提交，传指定的参数
3. 而攻击网站B在访问网站A的时候，浏览器会自动带上网站A的cookie

4. 因此网站A在接收到请求以后可判断当前用户是登陆状态，因此根据用户的权限作具体的操做逻辑，形成伪形成功

   3.2 原理

• CSRF可以攻击成功在于Web的身份验证机制->使用cookie

  3.3 防护手段

1. HTTP Referer 头验证
   根据Http协议,发送Http请求时会带有Referer字段,其值由浏览器负责添加,为发起该请求的站点的域名.可是,该值并非必定能获取到,取决于浏览器实现和用户配置是否启用.
   结论：不可靠
2. Anti CSRF Token
   在进行页面请求的时候,由服务端生成随机动态Token附加到Session或header中.在进行后续请求时,不论是Get/Post/Form都须要带上该Token,由服务端验证.
   结论:常见手段
3. HTTP自定义头
   在请求的HTTP头部中附加自定义头部.
   结论:常见手段

4. clickjacking(点击劫持)

4.1 例子

1. 用户C访问网站A,在网站A的页面中嵌入了网站B的内容,如新闻、图片等
2. 用户C点击看见的网站B的内容

3. 该点击事件被劫持,从而让用户访问其不该该访问的内容
   注：单一的点击劫持也许粗略一看并不能达到太恶略的攻击效果,但若是联合 XSS+CSRF+clickjacking,能够作的事情就不少了。

   4.2 防护手段

   HTTP协议中的头部 X-Frame-Options

• DENY：表示该页面不容许在 frame 中展现，即使是在相同域名的页面中嵌套也不容许
• SAMEORIGIN：表示该页面能够在相同域名页面的 frame 中展现
• ALLOW-FROM：表示该页面能够在指定来源的 frame 中展现。

5. 其余

1. HTTP Strict Transport Security (HSTS)
   告诉浏览器只能经过HTTPS访问当前资源，而不是HTTP.阻止黑客的中间人攻击.
   使用场景，好比升级全部http连接到https。
2. Cookie security

• Secure
  标记为 Secure 的Cookie只应经过被HTTPS协议加密过的请求发送给服务端
• HttpOnly
  标记为 HttpOnly 的Cookie没法经过JavaScript的 Document.cookie API访问,它们只发送给服务端

refs:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP