日常开发工作遇到的安全问题整理

要提供互联网服务，当你在开发代码的时候必须时刻保持安全意识，确保不会因为代码的不确定性而导致服务不安全。

 

为了确保你的web内容安全，需要遵循一些常规的准则：

1、别相信表单，必须过滤所有的表单数据

2、别相信用户，不相信任何用户的行为

3、关闭全局变量，修改php.ini文件，设置register_globals = Off

4、推荐安全配置选项

    register_globals 设置为 off

    safe_mode 设置为 off

    error_reporting 设置为 off。如果出现错误了，这会向用户浏览器发送可见的错误报告信息。对于生产服务器，使用错误日志代替。开发服务器如果在防火墙后面就可以启用错误日志。

    停用这些函数：system()、exec()、passthru()、shell_exec()、proc_open()、和popen()。

    open_basedir 为 /tmp（以便保存会话信息）目录和web 根目录，以便脚本不能访问这些选定区域外的文件。

    expose_php 设置为 off。该功能会向Apache 头添加包含版本号的PHP 签名。

    allow_url_fopen 设置为 off。如果你能够注意你代码中访问文件的方式-也就是你验证所有输入参数，这并不严格需要。

allow_url_include 设置为 off。对于任何人来说，实在没有明智的理由会想要访问通过HTTP 包含的文件。

 

常见问题防御

 

SQL 注入攻击：

 

描述：

通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

 

危害：

1、查询数据库敏感信息，导致数据泄露。

2、非法操作数据库，添加、删除、修改服务器数据。

 

防御方法：

1、总是验证所有参数。例如，如果需要一个数字，就要确保它是一个数字。

2、总是对数据使用mysql_real_escape_string()函数转义数据中的任何双引号和单引号。

3、若使用PDO方式操作数据库，使用SQL参数化查询。

   为什么参数化查询能过滤SQL注入呢？

因为prepare ... Execute是分两步执行，pdo会采用模拟的方式来实现，先对数据做quote，然后把结果拼接成sql再执行（第一次传一个sql模板，第二次传查询参数，会把第二步传入的参数只做查询参数处理，不做语义解释，这样注入的条件就算执行了，也不会得到查询结果）。

 

XSS跨站脚本攻击：

 

描述：

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

 

危害：

1、盗取用户COOKIE信息。

2、跳转到钓鱼网站。

3、操作受害者的浏览器，查看受害者网页浏览信息等。

4、蠕虫攻击。

防御方法：

1、使用htmlspecialchars 过滤，

2、使用正则表达式过滤特殊字符和函数。

 

API接口安全：

 

描述：第三方直接通过调用接口，恶意刷接口、获取数据。

 

危害：

接口被恶意批量请求（重放攻击）。

恶意遍历接口，获取有价值数据。

 

防范方法：

1、系统层面API接口开启安全校验（即token验证），验证签名和有效时间，防止被爆刷；

业务层面还需要验证参数的合法性，对参数进行sign验证，防止遍历接口导致数据外泄（例如，如果不做参数验证，根据id遍历所有用户订单）。

 

账户安全：

 

描述：

用户或许系统的账号、密码、密钥信息在http传输过程被第三方挟持等情况而泄露，导致系统、用户账号安全问题发生。

 

安全措施：

1、传输过程，账号和密码参数加密传输；

2、数据存储，用户密码、支付key、密钥key等需要加密保存；

3、页面输出，用户相关信息需要加密再输出页面等。

 

系统命令安全：

 

描述：用户提交的参数用于执行系统命令。

解决：

1. 谨慎使用系统命令，对使用系统命令的地方需要进行安全评审

2. 对命令语句进行严格过滤

 

文件上传安全：

 

描述：

Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，或者没检测文件内容的合法性，就把文件保存在服务器上，甚至上传脚本木马到web服务器上，直接控制web服务器。

 

情况：

1. 未限制扩展名

2. 未检查文件内容

3. 病毒文件

 

解决方法：

1. 使用安全的，可信任的上传组件。

2. 检查文件扩展名，保证文件的类型正确。

3. 检查文件内容，保证用户不伪造文件类型。

 

cookie安全设置：

解决：

cookie httponly flag：在用到用户名登陆密码之类的安全性比较高的cookie的时候，可以在cookie中设置httponly属性，该属性只允许php等访问cookie，而不允许js访问。

cookie secure fla：在涉及到https这样的情况，需要对cookie加密传输，那么可以设置这个属性

 

session安全：

1. SESSION是保存在服务器端的，具有比COOKIE一定的安全性。

2. 使用COOKIE的时候，如果长时间没有动作，可以设置一个时间值，来对COOKIE进行过期。

3. 尽量让用户每次的cookie值都是不同的，这样可以保证cookie被盗取也不能长期使用的问题。