常见的web攻击与防护

X-Frame-Options

举个例子

攻击者做了一个简易站点(newtaobiao.com),
网页上嵌入了淘宝的页面, 再使用一个透明的 iframe 覆盖在页面首层；
然后发链接给用户, 告诉这是淘宝的新网站

用户点击后发现和淘宝一模一样, 于是进行了登录, 发现使用上没有什么问题；
更进一步, 用户下单后看到手机上的原淘宝 APP 也会同步更新, 于是深信这是真网站；

攻击者此时在透明的 firame 上展示诱骗用户的文字, 用户就会误信是官方信息；

或者在特定页面遮挡页面的文字, 使用户未能看到真实信息；

防范办法

给响应的页面添加 X-Frame-Options 头部, 以告诉浏览器,
此网站不允许出现在 <firame>,<iframe>,<object> 标签内；

有三个值:
DENY # 表示该页面不允许在 frame 中展示,即使在相同域名的页面中嵌套也不允许
SAMEORIGIN # 表示该页面可以在相同域名页面的 frame 中展示
ALLOW-FROM url # 表示该页面可以在指定来源的 frame 中展示

可能的影响

目前发现这个 HTTP 响应头会带来的问题就是百度统计中的"热点追踪(页面点击图)“功能会失效,
这也说明百度统计的"热点追踪(页面点击图)“使用的是 frame 嵌入引用网页的形式,
这时候大家可以使用 X-Frame-Options 的 ALLOW-FROM uri 来指定百度统计域名为可 frame 嵌入域名即可；

1
2
3


nginx配置
add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com；
add_header X-Frame-Options:SAMEORIGIN；

sql注入防护

可能是最常见的攻击方式之一了

泛指因为没有对用户输入进行校验, 以至于执行了攻击者提供的 sql 语句；

例子

服务器接口 /api/user?id=10
期待接收的 id 是一个数值, 但拼接sql时没有做校验；
如 where id=? 期望最后的sql是 where id=10

但攻击者提供了一个 ‘10 or id!=0’, 最终被拼接为 where id=10 or id=0, 总是满足的条件, 于是造成了数据泄漏。

防御办法

只能是服务器端增加校验逻辑；

对参数的类型和格式进行校验，在正式处理前进行合法性检查；
对输出也进行一次校验；
一般来说常见 ORM 框架都做了相关的防止 SQL 注入的设计, 可以升级到支持较好的框架。

CSRF 跨站

Cross Site Resource Forgery(跨站请求伪造)
简单说就是用户在别的网站被动发起了一次对主站的请求。

原理

利用浏览器对部分资源的默认行为，
比如 img 是用 GET 请求获取 src 渲染的, a 标签的 to="_blank"跳转也会对 src 使用 GET 请求。

在用户已经登录正常网站后, 木马网站调用用户原来的 cooike 和伪造内容向正常网站发起请求；

例子 1

攻击者进行留言, 留言的内容包括

1

<img src="/api/xxx-xxx?text=2"/>

其它用户浏览到此内容后, 浏览器会默认对此 src 地址发起 get 请求；
如果这个 src 是本网站, 就相当于自动为用户执行了一次请求；
可以是注销帐号, 或者是删除某记录, 或者是代为发布信息或交易。

如果这个 src 是攻击者的地址
则这次 get 请求的 Reffer 中有着原始页面的 url
这个 url 中可能会泄露用户的 id,或其它隐私参数

例子 2

攻击者在网站上传了恶意网站的一张图片地址链接
普通用户浏览到这个位置, 浏览器会自动加载此图片, 将发起一次 get 请求
攻击着通过对这次请求中的 header Reffer 找到用户请求时的原始页面地址的 URL
拿到包含的隐私信息

例子 3

用户访问 A 网站, 在未关闭页面的情况下, 新开 tab 页访问 B 网站；
B 网站上有恶意内容要求访问 A 网站的某接口；
浏览器将主动发起对 A 网站的情况, 此时用户本地与 A 网站的会话还有效；
虽然此次请求的 Reffer 会是网站 B, 但 A 网站还是进行了处理

漏洞发现

简单的办法就是看 get 接口没有对 Reffer 进行检测

防护办法

防止跨站攻击

每个 get 请求都验证 Reffer, 非本网站域名都予拒绝
通常将一个称为 CSRF 令牌的 token 发送到浏览器；
每次发出非 get 请求时, 都会通过 header 发送并验证此令牌
如果是 get 请求, 就在 url 内加入
这样如果不是在自身页面发起的请求, 在 B 网站发起时, 是获取不到这个 token 的

防止恶意代码触发用户发起的请求更改数据

get 操作不参与写库类动作；
接口请求中附带一个时间戳值, 比对用户打开此页面和发起接口请求的时间差, 太短则拒绝请求

防止隐私泄露

不通过 URL 传递票据或敏感信息
即便向恶意网站发起了请求, 也不会泄露敏感数据
格式化用户上传的内容, 只限定为纯文本展示