Web安全,常见攻击防范

Web安全

数据库部分

1. 释放固定权限给特定用户.

 grant all on *.* to 'username'@'%' identified by 'password';

• 权限：all ：所有权限； select ：查询权限
• 库名：* ：所有库；test ：指定test库
• 表名：* ：所有表；test ：指定test表
• 用户名：随便写必需加引号
• IP地址：% ：表示所有IP地址，必需加引号。

2. 使用视图.

create view ds_vuser as select id,tel,sex,portrait_url,name,status from ds_user

Tp在使用视图的坑,在平常使用视图的时候,我们通常会起一个名字叫做v_user,但是tp由于数据库前缀的问题,
我们需要设置的视图名称得和表前缀一致.即ds_vuser. 另外需要注意的是 大小写问题,在tp中对于M和D的参数的大小写是敏感的
当设置表前缀为ds_时,D(‘vuser’)对应表名是ds_vuser;而D(‘vUser’)对应表明为ds_v_user.

视图对于安全的影响,视图可以配合上面的授权一起使用,可以完成在不修改表结构的前提下,限制用户对表的部分数据的操作.
即,让给用户视图(view)的授权,而不是原始表(table)的授权,二者在授权上无任何区别.

3. mysql防注入.

在Tp中,更多是一些细节的体现
如 where("id = $id") 就不是安全的,
而where(array('id'=>$id))则会被tp进行转义和过滤的操作.

使用原生php的时候,则要使用mysqli和pdo的预编译和参数绑定来防止sql注入.

4. 密码sha1加盐加密.

robots.txt

Robots协议（也称为爬虫协议、机器人协议等）的全称是“网络爬虫排除标准”（Robots Exclusion Protocol），网站通过Robots协议告诉搜索引擎哪些页面可以抓取，哪些页面不能抓取。

Robots协议是网站出于安全和隐私考虑，防止搜索引擎抓取敏感信息而设置的。

身份验证和权限控制

基于角色的权限访问控制（Role-Based Access Control）.

防范XSS攻击

1. XSS攻击是什么

跨站脚本攻击(Cross Site Scripting)

原理:恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

1. 常见的两种防范方式

• 过滤 htmlpurifier

• 转义

遇到的一个坑,一般的富文本编辑器为了安全考虑,会自动转义文本.如ueditor,但是tp的I()方法或者create()方法也进行了转义,导致通过富文本编译器添加的文本实际被转义了两次,在回显的时候,无法正确显示.

防范CSRF攻击

1. CSRF攻击是什么
   

CSRF（Cross-site request forgery）跨站请求伪造.
简单来讲,就是攻击者利用你的身份信息,以你的名义发送了恶意请求

例子:

一个通常的例子是这样的,银行系统的转账是通过http请求来完成转账操作的.恶意用户通过伪造http请求(一般是一个链接或者就是一个表单的自动提交代码)来达到转账的目的.
这件事可以完成的原因在于,一般情况下我们的身份验证是通过会话信息cookie拿到session信息来判断的,如果用户登录了银行系统,而且依然在会话周期有效期内,当这个浏览器试图加载一些文件或者诱导用户点了某些链接之后,用户的浏览器就带着身份信息完成了一次转账请求.

这和多窗口浏览器以及cookie的自动提交机制都有关联.

防范措施:

1. 验证码,也就是每次进行提交都进行验证码验证,但是这会影响用户体验
2. 通过判断请求头的referer头来甄别用户,但是这可以被伪造,有时候一些特殊的原因,请求头的referer也会为空,所以也不太可靠
3. 在返回的数据中加防伪标志,这主要是在服务器响应html数据的时候,在里面加入一个token令牌,当用户提交请求的时候,先验证token令牌的正确性,如果正确了在继续操作.

我目前看到的所有框架都使用的是这种方式,比如说thinkphp的表单令牌,lavarel的csrf_token,workpress里面也有类似的机制

字段验证

注意: 前后端都做

• 前端做的意义在于减少不必要的请求
• 后端做的意义在于安全验证

有人会觉得前端做了,后端在做就不是很有必要性了,但是事实并非如此,原因有二:
1. 程序员的终极法则,不要相信任何输入.前端工程师不能相信用户的输入;后端工程师不能相信前端的输入.
2. 即使你的前端完全值得信赖,也不要忘记并非所有的请求都来自浏览器.

还有一个值得注意,但是经常被忽视的是,在极端情况下也不要相信 SERVER和 _ENV的值,他们也是可被修改的,原因如上.

php.ini的安全配置

1. 生产环境关闭错误信息显示,记得同时打开错误日志记录
2. 可以禁用一些函数的使用.

另外需要注意的是,之间会推荐打开php的安全模式,但是它在php高版本已经被废弃了,而且打开它会出现很多文件操作和权限方法的问题,谨慎操作.不推荐

以上就是Web编程中,常见的安全问题.

备注

实际上,以上的策略,算了防范了两部分人.

• 一部分是’自己人’,也就是程序员,不要被程序员搞个定时任务把库删了.
  这部分主要体现在数据库权限和视图的使用,当然视图的使用并不仅限于控制程序员的操作权限,很多时候视图的更主要的用处是简化数据库操作.

• 另一部分,则是大家都清楚的各种各样的用户.