安全规范

web攻击和防御

一、跨站脚本攻击

发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。
1). 反射型XSS
它是通过诱使用户打开一个恶意链接，服务端将链接中参数的恶意代码渲染到页面中，再传递给用户由浏览器执行，从而达到攻击的目的。
2). 持久型XSS
持久型XSS将恶意代码提交给服务器，并且存储在服务器端，当用户访问相关内容时再渲染到页面中，以达到攻击的目的，它的危害更大。
3).Cookie劫持
Cookie中一般保存了当前用户的登录凭证，如果可以得到，往往意味着可直接进入用户帐户，而Cookie劫持也是最常见的XSS攻击。
防御Cookie劫持的一个简单的方法是在Set-Cookie时加上HttpOnly标识，浏览器禁止JavaScript访问带HttpOnly属性的Cookie。
防御：
1). 输入检查
对输入数据做检查，比如用户名只允许是字母和数字，邮箱必须是指定格式。一定要在后台做检查，否则数据可能绕过前端检查直接发给服务器。一般前后端都做检查，这样前端可以挡掉大部分无效数据。
对特殊字符做编码（htmlspecilchars）或过滤(strip_tags)，但因为不知道输出时的语境，所以可能会做不适当的过滤，最好是在输出时具体情况具体处理。
2). 输出检查
对渲染到HTML中内容执行HtmlEncode，对渲染到JavaScript中的内容执行JavascriptEncode。将输出数据放到input、testarea文本框内也不会执行。

二、SQL注入

由于用户提交的数据被当成命令来执行而造成的。
例子：如果用户提交的username参数是leo’; drop table user–，那执行的SQL为：
select * from user where username = ‘leo’; drop table user–’
防御：
1）最好的方法是采用预编译语句集（PreparedStatement），它内置了处理SQL注入的能力，只要使用它的setXXX方法传值即可。
原理：sql注入只对sql语句的准备(编译)过程有破坏作用，而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,而不再对sql语句进行解析,准备,因此也就避免了sql注入问题.
2）使用正则表达式过滤传入的参数
3）字符串过滤（判断非法字符truncate、drop）

三、跨站请求伪造（CSRF）

是由于操作所需的所有参数都能被攻击者得到，进而构造出一个伪造的请求，在用户不知情的情况下被执行。
例子：如果a.com网站需要用户登录后可以删除博客，删除博客的请求地址如下：
GET http://a.com/blog/delete?id=1
当用户登录a.com后，又打开了http://b.com/b.html（黑客提供），其中有下面的内容：

这时会以用户在a.com的身份发送http://a.com/blog/delete?id=1，删除那篇博客。
防御：
1）referer检查：检查请求header中的referer也能帮助防止CSRF攻击，但服务器不是总能拿到referer，浏览器可能出于安全或隐私而不发送referer，所以也不常用。倒是图片防盗链中用得很多。
2）Anti CSRF Token：更多的是生成一个随机的token，在用户提交数据的同时提交这个token，服务器端比对后如果不正确，则拒绝执行操作。
3）验证码：CSRF是在用户不知情的情况下构造的网络情况，验证码则强制用户与应用交互，所以验证码可以很好得防止CSRF。但不能什么请求都加验证码。

安全编码定义了一套可以集成到开发生命周期中的通用软件安全编码规范。采用这些规范将减少最为常见的安全漏洞，也可以作为在代码review时安全checklist名单。
一、输入验证
认为所有客户端传输的数据皆不可信，验证所有来自客户端的数据,包括:
所有请求参数
URL
HTTP 头信息(比如:cookie 名字和数据值)
环境信息
上传文件
验证正确的数据类型，数据范围，数据长度，数据格式
尽可能采用白名单和正则表达形式，验证所有的输入
丢弃任何没有通过输入验证的数据，不允许在程序里直接使用$_SERVER,$_GET, $_POST,$_COOKIE, $_FILES,$_ENV, $REQUEST获取外部数据
文件的路径与名称的过滤：
文件名中不能包含二进制数据，否则可能引起问题。同时需要限定文件名的长度。
虽然Unix系统几乎可以在文件名设定中使用任何符号，但是应当尽量使用 - 和 _ 避免使用其他字符。
一些系统允许Unicode多字节编码的文件名，但是尽量避免，应当使用ASCII的字符。
如果用户不需要知道存储的文件名。建议使用md5或者其他方式重命名文件名指定文件后缀。
不建议只使用转义，使用转义必须有其他控制手段，转义函数可以参考htmlentities，htmlspecialchars
如果任何潜在的危险字符必须被作为输入，请确保您执行了额外的控制，比如:输入转义、输出编码、特定的安全 API、以及在应用程序中使用的原因。部分常见的危险字符包括:< > ” ’ % ( ) & + \ \’ \” 。
二、访问控制
除了那些特定设为“公开”的内容以外,对所有的网页和资源要求身份验证。
对资源获取的时候都需要判断是不是该用户能操作和获取的。避免越权和全面遍历。
对操作和浏览尽量小的权限，提升权限的时候需要进一步验证。
对于有流程限制的操作，注意限制跨步提交。
当设计外网访问API接口时应注意：
防止请求内容篡改和伪造
防止请求内容被重放攻击
确保请求是由应用方所发起
尽可能使用HTTPS传输
如果只有以上几点可以使用phplib里封装的security/api组件
当设计JS或者客户端请求接口时应注意：
校验请求refer，不仅有域限制，而且要严格限制请求发起地址
关键数据变更可以使用验证安全token，可以考虑验证码
在关键位置要做防止暴力尝试控制，比如：注册登录下订单操作
使用频率控制器，限制尝试次数
使用验证码区别人机
在做HEADER跳转时，url的地址不能是外界传入，尽量控制是本域跳转。如果必须用户传入跳转地址，添加一个用户不可控的随机值参数，如果验证成功则直接跳转，验证失败进行跳转提示(参考google)
管理系统等内部系统，务必处于内网保护下。禁止公网一切访问。
三、数据保护
对隐私和主要机密信息，在存储设备上应该做加密处理，用来验证的信息使用散列函数求值存储（比如密码），用来获取的信息使用对称加密算法AES处理（比如手机号身份证号码）。
对数据采用一定的措施降低泄露后威胁程度，比如（给身份证图片添加无法擦除水印，避免用于其他用途）。
限制只有授权的行为才能访问隐私和主要机密信息，比如（文件系统设置为私有不对外公开，每次获取需要授权，可以参考oss）。
不要在客户端上以明文形式或其他非加密安全模式保存密码、连接字符串或其他敏感信息。 这包括嵌入在不安全的形式中:MS viewstate、Adobe flash 或者已编译的代码。
包含敏感信息的数据传输的采用加密传输比如（用户账户密码提交）。

四、关闭的服务
线上WEB服务器禁用 PHP以下命令：system,passthru,shell_exec,exec,popen,phpinfo,proc_close,proc_open,dl,show_source,get_cfg_var，如果需要执行单独申请。
错误日志及调试信息，禁止线上打印输出一切无关信息，关闭错误直接输出。禁止线上直接file_put_contents。
线上数据库只提供select,update,delete,insert功能，默认禁止建表，删表，清空表操作。
禁止私自开启 对外socket端口服务，需要和运维商讨添加安全策略。