WEB基础的最后一篇，一起来了解一下web开发中常常碰到的安全问题。
编写你的PHP开发框架：常见安全风险及防范
XSS
XSS即人们经常说的跨站脚本攻击（Cross Site Scripting），因为如果缩写成CSS时会与更为人熟知的样式表的缩写混淆，因此，通常将跨站脚本攻击缩写为XSS。
XSS是通过让用户执行一些恶意注入的脚本的方式来进行攻击的，针对的通常是用户层面，比如获得用户的cookie，或者以用户身份做一些事情。
恶意脚本的注入方式有两种： 反射型和存储型。
反射型
攻击者通过将恶意脚本加到有XSS漏洞的网站的url中，再骗取用户点击，用户点击后，恶意脚本被触发。以下是一个演示例子：
$name = $_GET['name'];
printf('你好，%s', $name);
?>
上面这个例子，name参数并没有做任何处理就直接回显，攻击者就可以通过构造类似index.php?name=alert('hello');的方式注入恶意脚本。
- 目前很多浏览器都有防XSS的功能，所以如果你在浏览器上直接构造上面的url可能不会成功。
- 示例只用了一个alert，但实际上只要能注入script，就可以执行几乎任意脚本。
存储型
反射型的XSS，恶意脚本并没有保存在网站中，而是被攻击用户主动点击后才会受到攻击，而存储型，则是通过预先注入的目标站点的方式。
攻击者通过UGC或其它的方式将恶意脚本提交并保存在网站服务器中，当用户访问到能调用该恶意脚本的页面时被触发。
同样是上面的例子，如果显示的$name是从数据库读取的，而这个$name在保存在数据库和从数据库读出来时都没有进行XSS的过滤，那每一个访问这个页面的用户都会被攻击到。
可以想像得到，存储型的危害程度要比反射型大很多。
除了对用户进行攻击，XSS也可用作对站点进行攻击，比如利用一个流量很大的有XSS漏洞的网站，去DDOS一个小站点。
除了反射型和存储型，还有一种DOM型，其实质也是反射型。
了解了XSS的原理和危害后，那要怎么防范呢？
对付XSS只有一个忠告： 用户输入和提交的任何内容都是不可信的。请记住这句话，在安全领域，这是永恒的真理。
记住这一点，然后再去了解一下哪些内容可能会造成XSS(事实上除了 “”还有很多内容都是危险的)，想尽办法过滤掉它。
CSRF
CSRF，即跨站点请求伪造(Cross—Site Request Forgery)，也是一种危害极高的漏洞，就连gmail，也出现过CSRF漏洞。
下面先以一个简单的例子来说明：
假设有一个银行网站(xxxbank.com)，A和B都有帐号，如果A要给B转帐1万块，则需要访问
http://xxxbank.com/transfer?from=A&to=B&amount=10000
此时，银行网站会判断当前的操作请求是否有登录，已登录且登录的用户确实是A才会给B转钱，也就是说，B自己访问这个连接是不会完成转账的。
但是，如果A在已经登录了银行网站之后，访问了B给出来的一个网页，在该网页中添加类似如下内容：
这个时候，A去访问B所给出的这个网页时，浏览器会自动请求这个src指向的转帐连接，同时会带上A在xxxbank.com的cookie。
因为A这时是已登录状态，所以，该转帐连接能成功执行。
这个过程所说的，就是跨站点请求伪造，也就是说在A在访问某站时，在不知情的情况下，该站伪造了一个请求，以A的身份访问了A已登录的其它网站，完成相关操作。
防范：
- 服务端判断Referer来自同一网站。
加上Referer判断是可以防范CSRF攻击，但并不保险，因为一些老的浏览器可以修改Referer。新的浏览器虽然不能修改Referer，但用户却可以因私隐理由禁止发送Referer，导致正常的请求失败。
- 在请求的url、表单域或header中，加上一个由服务器生成的token，再由服务器验证。
CSRF攻击之所以能够成功，是因为黑客伪造用户的请求，该请求中用户验证信息都是存在于cookie中，而触发请求时cookie会自动被带上，所以能通过身份认证。
所以，需要找一个在cookie之外的认证凭证，比如可以在登录时服务器生成一个随机的token，并保存在session，同时将该token返回给客户端，客户端随后的请求中，将该token按照约定放在url或者header、表单域等提交给服务器。服务器就可以根据token来判断请求是否正常的请求。
越权访问
越权访问，又称BAC（ Broken Access Control ）, 属于一种常见错误， 危害性极大。
先用一个简单的例子说明一下什么是越权访问。
假设在一个多用户博客系统中，所有用户的文章都保存在同一个表中，只以“用户ID”来区别是属于谁的文章。如果用户要删除文章，通常会指定一个文章ID来操作，于是，有些开发者就会写出类似下面的代码：
if(isLogin()) { // 已登录才进行处理
$sql = sprintf('delete from article where id=%d',$_GET['id']);
$db -> execute($sql);
}有没有看出来？上面的代码只判断了用户已经登录，就直接删除了指定的id的文章，这样一来，用户不但能删除自己的文章，还能删除其它任意用户的文章，这就是越权。
简单理解就是用户可以操作(包括查看、更新、删除)本身不属他的没有获得授权的内容。
防范：处理用户内容时，要多考虑用户身份问题。必要时使用统一的权限判断方法，进行统一拦载调用。
越权访问通常还包括在社会学领域，比如由于B的疏忽，A拿了B的帐号登录。
SQL注入
SQL注入是现在很普遍存在的一种攻击手段，就是通过url参数或表单数据等提交一些特殊的内容，从而构造出非法的SQL语句，最终达到欺骗服务器执行恶意的SQL语句的目的。
SQL注入本质上与XSS类似，不同的是XSS注入的是脚本，SQL注入是注入恶意的SQL语句。
以下是一个简单的例子：
// 这是一个模拟处理用户登录的程序，通过$_POST获得用户名和密码，进行登录校验
$sql = sprintf("select * from user where name='%s' and password='%s'",
$_POST['name'],
$_POST['password']);
// echo $sql;
// 执行查询并获得结果
$re = $db -> query($sql);
if($re) {
echo '登录成功';
}
>
如果不做安全处理，当用户提交的数据如下：
name="aaa"
password="bb' or '1'='1"
这个时候，就发生了注入，$sql的值就会变成:
select * from user where name='aaa' and password='bb' or '1'='1'
通过类似的手段，攻击者就可以通过精心构造出很多非法的SQL语句，从而完成SQL注入。
防范：
首先，还是那句话： 用户输入和提交的任何内容都是不可信的。
在构造SQL查询时，要特别注意对用户输入数据的处理。
然后建议尽量使用Prepare方式构造和执行SQL语句。
不适当的存储和日志
不适当的存储指的是一些敏感信息，存储时没有经过足够的保护。
比如用户表里的密码，如果没有进行合理的加密存放，一旦数据表被泄漏出去，就会带来具体的影响。比如很多开发者只是将密码做一个md5甚至是明文放到库里，这是极其危险的。
另外，WEB开发经常需要记录一些文本日志，有时候你并不知道这些日志到底都有谁能看到，如果日志里存有一些敏感信息，那就会造成信息泄露。比如有些开发者会在登录时将用户的帐号密码打印在日志里。
防范： 对敏感信息的存储和使用，要多注意保护。
WEB服务器安全
WEB服务器安全是一个很复杂的话题，基于本人的水平有限，这里不打算展开，只提醒一下很多开发者都会犯的错误 - 没有禁止非必要的资源请求
非必要的资源，包括：
- 附加在代码里的一些设计文档、一些开发时用的辅助脚本、甚至是数据库脚本。
- 在代码里被引用的、不应该直接访问的文件，比如配置文件。
- 某些场景下使用文本保存的数据。
- 服务器本身的其它目录中的文件。
非必要的资源有很多很多，可能很难列得完整，其实我们可以反过来，只对需要访问的资源开放权限即可，以下是防范建议：
- 只开放一个WEB访问目录，并将请求锁定在此目录(禁止访问其它目录)
- 只开放对应的扩展名，禁止txt、inc等其它扩展的访问。
- 如果可以，采用单入口(即web目录只有一个index.php)，禁止除了入口文件外的其它资源的请求。
小结
上面简单列举了在WEB开发中经常会碰到的一些安全风险和防范，最后，我们列举了一些其它的安全话题，有兴趣的朋友自己可以尝试深入去了解一下：
- 爬虫和反爬虫
- 图形验证码
- 数据加密解密
- 服务器高可用(比如DDOS、缓存击穿)
安全领域是一个很复杂的领域，绝不可能在短短的篇幅中就能讲清楚，这也需要开发者在平时的工作和学习中多留意。总之，安全无小事。在安全问题上，绝不能偷懒和掉以轻心。
到这里为止，web基础部分的内容已完成，下面是内容提纲：
- 请求处理流程
- http协议基础
- 用户会话
- 常见安全风险和防范
下一篇开始，开始讲一下PHP语言的一些基本特性。
本文来自投稿，不代表本人立场，如若转载，请注明出处：http://www.souzhinan.com/kj/257501.html