月度归档： 2015年4月

为了避免网页被 frame 或者 iframe 嵌套，可以设置 Frame-Options 禁用。

Frame-Options 目前还未完全成为标准，仍需要使用 X-Frame-Options。

X-Frame-Options 值列表

例如在 www.main.com frame-options.php 中增加 X-Frame-Options header，然后在 www.third.com frame.php 中增加 iframe，指向 frame-options.php，效果如下：

代码示例：

www.main.com

// 文件 frame-options.php
<?php header('X-Frame-Options: DENY');?>
You cannot see this page.

www.third.com

// 文件 frame.php
<iframe src="http://www.main.com/frame-options.php"></iframe>

CSRF 全称是 Cross-Site Request Forgery，指攻击者盗用了用户的身份，以用户的身份发送恶意请求。

CSRF 攻击流程

1. User 登录网站 A（存在 CSRF 攻击漏洞的网站）
2. User 在没有网站 A 的情况下，使用同一个浏览器访问危险网站 B
3. 网站 B 模拟 User，发送恶意的 GET 或者 POST 请求（通过 iframe、js 等）到网站 A。比如让网站 A 删除用户数据
4. 网站 A 在没有防范的情况下，破坏或者泄露了用户数据

网站 A 防范 CSRF 攻击的简单方式是在用户提交表单时，增加一个令牌验证。

令牌验证

在网站 A 增加简单令牌

<?php
function gen_csrf_token()
{
	session_start();
	return md5(session_id());
}

function verify_csrf_token($token)
{
	session_start();
	return $token = md5(session_id());
}
?>
<form action="/user/update" method="post">
	<input name="csrf_token" value="<?=gen_csrf_token()?>"/>
	<input name="sex" value="man"/>
	<input type="submit"/>
</form>

当表单提交时，执行 verify_csrf_token 判断是否令牌是否正确，继而认为不是第三方网站伪造的请求。

HTTP_REFERER 验证

验证 http_referer 也能够从一定程度上降低 CSRF 攻击风险。现代浏览器是不允许修改 HTTP_REFERER 头信息的。

CSP 全称是 Content Security Policy，控制浏览器在加载网络资源时，告知浏览器哪些资源是可信的、安全的。可以有效地降低和杜绝 XSS 攻击。

如何产生 XSS 攻击，可以参考 http://blog.zhengxianjun.com/2015/web-security-xss/。

有时候即便整个网站增加了 XSS 防注入，也可能在迭代过程中存在遗漏。

浏览器不能区分哪些资源是安全的，一旦下载之后就会执行。（有些浏览器可以识别简单的 XSS 注入）。

CSP 就是为了告诉浏览器哪些资源是可信任的、安全的，通过白名单去加载网络资源和执行。这样即使网页存在 XSS 注入，出现损失的可能性也会大大地降低。

比如：

Content-Security-Policy: script-src https://s.fiaox.com

那么浏览器只会信任来自 s.zhengxianjun.com 的脚本，这样即使网站被注入了第三方站点脚本或者内联，也不会执行，那 XSS 攻击也就失效了。

代码示例：

<?php header('Content-Security-Policy: script-src https://s.fiaox.com');?>
<script type="text/javascript" src="https://code.jquery.com/jquery.js"></script>
// 支持 CSP 则不会加载来自 jquery.com 的脚本

以上代码分别在 IE、Chrome、Firefox 中的效果。

在 IE10 中，似乎没有支持 CSP，jquery.js 被正常加载和执行。这是因为早期 CSP 没有规范，IE 识别 X-Content-Security-Policy，但并不是完整支持。

Chrome 正确识别了 CSP，并且说明了原因。

Firefox 正确识别了 CSP，并且说明了原因。

CSP 是帮助浏览器创建了一个网络资源白名单。

CSP 规则列表

Content-Security-Policy: script-src 'self' s.zhengxianjun.com;style-src 'self';img-src 'self'

• 多个指令之间用英文分号隔开；
• 指令的值不是域名时需要引号引起来；
• 指令重复以第一个为准。

以上指令除了 sandbox、report-uri 是比较特殊的值，其余指令可以接收 ‘self’、data、域名 等值。

指令示例

report-uri 会接收到一个 post 请求，包含 CSP 阻止的详细信息。

虽然 CSP 能够有效降低 XSS 攻击，但是不要指望它可以完全杜绝 XSS 攻击。

为了让产品能够顺利过渡到 CSP，可以通过 Content-Security-Policy-Report-Only 先收集 CSP 报告，根据报告修正被阻止的正确资源，再启用 CSP。使用了 Content-Security-Policy-Report-Only 则一定要配置 report-uri。

示例：

Content-Security-Policy-Report-Only: script-src 'self'; report-uri https://www.zhengxianjun.com/csp/report

P3P 全称是 The Platform for Privacy Preferences，控制用户在在浏览网页时，如果网页中包含第三方站点资源，是否接受第三方站点设置的 cookie。

举个例子：

user 访问 www.main.com, 该站点加载了第三方网站 www.third.com 的网页（通过iframe）或者静态资源（css, js, img），是否接受 www.third.com 设置的 cookie。

默认情况下不允许保存第三方 cookie，假如第三方站点在 header 中设置了 P3P 相关信息，则可能允许跨域访问隐私数据。

IE 浏览器隐私设置：

Chrome 浏览器隐私设置：

配合这两幅截图说明第三方 cookie 在 IE、Chrome 中是否有效。两幅截图显示 IE 阻止第三方 cookie，Chrome 接受第三方 cookie。

代码示例：

www.main.com setcookie

// file http://www.main.com/setcookie.php
<script src="http://www.main.com/setcookie.php"></script>
<!-- <iframe src="http://www.main.com/setcookie.php"></iframe> -->

www.third.com setcookie

// header('P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"');
setcookie('p3p_cookie_key', 'time_' . time(), time() + 60, '/', '.third.com');

www.third.com getcookie

// file http://www.third.com/getcookie.php
echo 'p3p_cookie_key:' . $_COOKIE['p3p_cookie_key'];

访问 http://www.main.com/setcookie.php，网页会通过 iframe 或者 script 访问 http://www.third.com/setcookie.php, 此时浏览器不一定接受来自 www.third.com 的 cookie。也就是立即访问 http://www.third.com/getcookie.php，可能获取不到 cookie 信息。

当 www.third.com setcookie.php 输出 P3P 头信息时：

1. 访问 http://www.main.com/setcookie.php
2. 访问 http://www.third.com/getcookie.php 可以获取到 cookie p3p_cookie_key

网页上所有资源浏览器都可以访问，但出于安全考虑，浏览器对此进行了限制，产生一些安全词汇。

P3P Header is present [引用]

在 Web 安全领域有一个词汇经常被提到——XSS。简单地说，就是网页被不信任源注入了可执行脚本。

比如：

// a.php 文件内容
<?php $email = $_GET['email'];?>
<input type="hidden" name="email" value=<?=$email?>""/>

// 访问 a.php?email=a%40a.com"%20onclick%3D"alert(1)

// 在网页没有采取任何安全策略的情况下会弹出一个对话框

// 最后的火狐浏览器的截图是攻击者希望看到的

以上代码分别在 IE、Chrome、Firefox 中的效果。

IE 会检测可能的跨站脚本操作。

Chrome 也会检测 XSS 攻击，说明了为何出现此提示（its source code was found within the request），也说明了如何更好地工作。

不是我黑它，真没有，火狐版本 37.0.2。

这个内联的 onload 并没有包含 <script> 标签，但是它仍然可以执行。这个示例中只是弹出一个对话框，可能还有更严重的破坏行为。

为了避免出现 XSS 攻击，不能仅仅依靠浏览器帮我们检测，还需要我们有意识地去过滤这些不安全的脚本。