Coding-everyday

# 1. SQL 注入

所谓 SQL 注入，就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，后台执行 SQL 语句时直接把前端传入的字段拿来做 SQL 查询。

# 1.1. 防御

  • 永远不要信任用户的输入。
  • 永远不要使用动态拼装 sql，使用ORM可以大大降低sql注入风险
  • 不要把机密信息直接存放

# 2. XSS：跨站脚本攻击（Cross-site scripting）

  1. 比如在新浪博客中写一篇文章，同时偷偷插入一段<script>
  2. 攻击代码中，获取cookie，发送到服务器
  3. 发布博客，有人查看博客内容
  4. 会把查看者的cookie发送到攻击者的服务器

# 2.1. XSS防范

  • 将<和>替换

# 3. CSRF：跨站请求伪造（Cross-site request forgery）

CSRF攻击：攻击者盗用了你的身份，以你的名义向第三方网站发送恶意请求。 CRSF能做的事情包括利用你的身份发邮件、发短信、进行交易转账等，甚至盗取你的账号。

  1. 首先用户C浏览并登录了受信任站点A；
  2. 登录信息验证通过以后，站点A会在返回给浏览器的信息中带上已登录的cookie，cookie信息会在浏览器端保存一定时间（根据服务端设置而定）；
  3. 完成这一步以后，用户在没有登出（清除站点A的cookie）站点A的情况下，访问恶意站点B；
  4. 这时恶意站点 B的某个页面向站点A发起请求，而这个请求会带上浏览器端所保存的站点A的cookie；
  5. 站点A根据请求所带的cookie，判断此请求为用户C所发送的。

受害者只需要做下面两件事情，攻击者就能够完成CSRF攻击：

  1. 登录受信任站点 A，并在本地生成cookie；
  2. 在不登出站点A（清除站点A的cookie）的情况下，访问恶意站点B。

# 3.0.1. cookie 不是同一个 domain 下才会携带吗？为啥网站B 可以带着网站A的 cookie 请求 A 呢？

因为B里面嵌入了A的地址，所以向B发起请求后，会自动向A发起请求，相当于浏览器做了两次请求。

# 3.0.2. B 网站可以获取到A网站到cookie吗？

不能，也不需要

# 3.0.3. 从 B 这个站点访问 A 这个接口，已经跨域了，怎么能访问通呢？

通过 img 标签的 src 属性发起的请求是不遵循同源策略的，这也是跨域的另一个解决方法Jsonp 的实现原理

# 3.1. CSRF的防御

  1. 尽量使用POST，限制GET
  2. 将cookie设置为HttpOnly
  3. 增加token (在请求中放入攻击者所不能伪造的信息，并且该信息不存在于cookie之中)
  4. 通过Referer识别
  5. 在 HTTP 头中自定义属性并验证

# 4. 点击劫持

点击劫持（Click Jacking）是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

对于这种攻击方式，推荐防御的方法有两种。

  • X-FRAME-OPTIONS
  • JS 防御

# 4.1. X-FRAME-OPTIONS

X-FRAME-OPTIONS 是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选，分别是

  • DENY，表示页面不允许通过iframe的方式展示
  • SAMEORIGIN，表示页面可以在相同域名下通过iframe的方式展示
  • ALLOW-FROM，表示页面可以在指定来源的iframe中展示

# 4.2. JS 防御

因为普通页面的top对象为window，而iframe的top对象不等于window对象，可以在JS代码中：

if (top.location !== window.location){
    top.location == window.location
}

这样如果存在嵌套的iframe，页面就会进行跳转，避免的点击劫持。 但是这种防御方式并不完善，如果攻击者设置ifame的属性sandbox="allow-forms" 时防御就失效

# 5. 中间人攻击

中间人攻击是攻击方同时与服务端和客户端建立起了连接，并让对方认为连接是安全的，但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修改通信信息。

通常来说不建议使用公共的 Wi-Fi，因为很可能就会发生中间人攻击的情况。如果你在通信的过程中涉及到了某些敏感信息，就完全暴露给攻击方了。

当然防御中间人攻击其实并不难，只需要增加一个安全通道来传输信息。HTTPS 就可以用来防御中间人攻击，但是并不是说使用了 HTTPS 就可以高枕无忧了，因为如果你没有完全关闭 HTTP 访问的话，攻击方可以通过某些方式将 HTTPS 降级为 HTTP 从而实现中间人攻击。

← 事件委托 →