<form action="http://localhost/servlet/modify" method="POST">
<input>
<input>
</form>
当用户点提交时,就会触发修改操作。
攻击实例
如果“代码示例”中的代码,是 xxx.com 上的一个 web 应用,那么恶意用户为了攻击 xxx.com 的登录用户,可以构造 2 个 HTML 页面。
(1) 页面 a.htm 中,iframe 一下 b.htm,把宽和高都设为 0。
复制代码 代码如下:
<iframe src="https://www.jb51.net/article/b.htm"></frame>
这是为了当攻击发生时,受害用户看不到提交成功结果页面。
(2) 页面 b.htm 中,有一个表单,和一段脚本,脚本的作用是,当页面加载时,自动提交这个表单。
复制代码 代码如下:
<form action="http://xxx.com/servlet/modify" method="POST">
<input>
<input>
</form>
<script>
document.getElementById("modify").submit();
</script>
(3) 攻击者只要把页面 a.htm 放在自己的 web 服务器上,并发送给登录用户即可。用户打开 a.htm 后,会自动提交表单,发送给 xxx.com 下的那个存在 CSRF 漏洞的web 应用,所以用户的信息,就被迫修改了。
解决方案
CSRF 防御的原理是,在用户登录的时候,生成一个随机的 token,将它存储在 cookie中(默认情况,也可以放在 session 中),在生成表单时,生成一个隐藏域,隐藏域的值就等
于 token 的值。如果用户提交这个表单,就可以在接收用户请求的 web 应用中,判断隐藏域的 TOKEN 值是否和用户 COOKIE 中的 TOKEN 值一致,如果不一致或没有这个值,就判
断为 CSRF 攻击。攻击者无法预测每一个用户登录时生成的那个随机 TOKEN 值,所以无法伪造这个参数。
常见问题
(1) 为什么不直接验证 referer?
因为还有站内发出的 csrf,并且 referer 是可以被篡改的,是不可靠的数据
(2) 如果先发生 xss 攻击,攻击者可以拿到用户页面的 token 怎么办?
无解,请先做好 xss 防范。
文件包含
PHP 可 能 出 现文 件 包 含 的 函 数: include、 include_once 、 require、 require_once 、show_source、highlight_file、readfile、file_get_contents、fopen、file
防范方法:
对输入数据进行精确匹配,比如根据变量的值确定语言 en.php、cn.php,那么这两个文件放在同一个目录下'language/'.$_POST[‘lang'].'.php',
那么检查提交的数据是否是 en 或者 cn 是最严格的,检查是否只包含字母也不错,通过过滤参数中的/、..等字符。
HTTP 响应拆分
PHP 中可导致 HTTP 响应拆分的情况为:使用 header 函数和使用$_SERVER 变量。注意PHP 的高版本会禁止 HTTP 表头中出现换行字符,这类可以直接跳过本测试。
防范方法:
精确匹配输入数据
检测输入输入中如果有\r 或\n,直接拒绝
变量覆盖
PHP 变量覆盖会出现在下面几种情况:
遍历初始化变量
例:
复制代码 代码如下:
foreach($_GET as $key => $value)
$$key = $value;
函数覆盖变量:parse_str、mb_parse_str、import_request_variables，Register_globals=ON 时,GET 方式提交变量会直接覆盖
防范方法:
设置 Register_globals=OFF
不要使用这些函数来获取变量
动态函数
当使用动态函数时,如果用户对变量可控,则可导致攻击者执行任意函数。
例:
复制代码 代码如下:
<?php
$myfunc=$_GET['myfunc'];
$myfunc();
?>
防御方法:
不要这样使用函数
会话安全
HTTPOnly 设置
session.cookie_httponly = ON 时,客户端脚本(JavaScript 等)无法访问该 cookie,打开该指令可以有效预防通过 XSS 攻击劫持会话 ID
domain 设置
检查 session.cookie_domain 是否只包含本域,如果是父域,则其他子域能够获取本域的cookies
path 设置
检查 session.cookie_path,如果网站本身应用在/app,则 path 必须设置为/app/,才能保证安全
cookies 持续时间
检查 session.cookie_lifetime,如果时间设置过程过长,即使用户关闭浏览器,攻击者也会危害到帐户安全
secure 设置
如果使用 HTTPS,那么应该设置 session.cookie_secure=ON,确保使用 HTTPS 来传输cookies
session 固定
如果当权限级别改变时(例如核实用户名和密码后,普通用户提升到管理员),我们就应该修改即将重新生成的会话 ID ,否则程序会面临会话固定攻击的风险。
加密
明文存储密码
采用明文的形式存储密码会严重威胁到用户、应用程序、系统安全。
密码弱加密
使用容易破解的加密算法,MD5加密已经部分可以利用 md5破解网站来破解
参考方案
复制代码 代码如下:
md5(md5($password).$salt)
密码存储在攻击者能访问到的文件
例如:保存密码在 txt 、ini、conf、inc、xml 等文件中,或者直接写在 HTML 注释中