前端安全
XSS漏洞
XSS (Cross-Site Scripting)，是一个我觉得耳熟能详的前端安全问题。
通过构造特殊数据，在用户浏览器上执行特定脚本，从而造成危害（如以用户身份发帖、转账等）。
Case A: HTML DOM
< a href="/user/1" >{{ user_name }}< /a >
< a href="/user/1" >< script >alert(1)< /script >< /a >
Case B: HTML Attribute
< img src="{{ image_url }}" >
< img src="" onerror=" alert(1) " >
这个例子表明，如果只对尖括号进行 escape 是不够的，很多时候引号也需要被 escape。
简单来说，对不同输出场景，需要使用不同的 escape 规则。
解决方法：
在不同上下文中，使用合适的 escape 方式
不要相信 任何 来自用户的输入（不仅限于 POST Body，还包括 QueryString，甚至是 Headers）
CSRF漏洞
CSRF (Cross-site request forgery)，是一个知名度不如 XSS 但是却同样具有 很大杀伤力的安全漏洞。
它的杀伤力大正是因为很多开发者不知道这个漏洞。
解决方法：
给所有请求加上 token 检查。
token 一般是随机字符串，只需确保其不可预测性即可。
token 可以在 QueryString、POST body 甚至是 Custom Header 里，但千万不能在 Cookies 里。
检查 referer （请注意，这往往不能防御来自网站自身的 CSRF 攻击，
如用户评论中的 <img> 就是一个常见触发点）
后端安全
SQL 注入漏洞
所有 SQL 语句都使用参数化查询（推荐）或对参数进行 escape（不推荐）
权限控制漏洞
有地方都要进行权限检查（如是否已登录、当前用户是否有足够权限、该项是否可修改等），总之，不要相信任何来自用户的数据，URL 当然也是。例如：display，hidden 等标签
SESSION 与 COOKIE
Cookie 存储在浏览器上，用户可以查看和修改 Cookie。
Session 是存储在服务端的数据，一般来说安全可靠；大多数 Session 都是基于 Cookie 实现的（在 Cookie 中存储一串 SESSION_ID，在服务器上存储该 SESSION_ID 对应的内容）
IP 地址
只使用 REMOTE_ADDR 作为获取 IP 的手段
验证码
非一次性指的是，同一个验证码可以一直被用下去。一般来说，每进行一次验证码校对（无论正确与否），都应该强制更换或清除 Session 中的验证码
网友评论