编 写：袁 亮 时 间：2015-10-09 说 明：web安全规范 - 2、基本安全防御 一、外部输入过滤 1、所有外部参数，必须经过处理过滤 get参数、post参数（$_REQUEST）、cookie数据，$_SERVER中的referer，ua，ip等数据 2、所有过滤，以服务端验证为准，js客户端验证仅仅是为了增强用户体验 不允许仅仅是在js加了判断验证，服务端没有 3、只允许使用过滤后的数据，不允许在后面再使用过滤前的原始参数 $p = isset($_GET['p'])?intval($_GET['p']):1; //过滤参数 后面只允许只用$p,不允许出现任何直接调用$_GET['p']的地方 4、过滤方法 4.1 整型参数，一律采用intval转换 4.2 短字符串，采用正则验证，常用正则百度，或者参考统一类库 比如手机号、用户名、邮箱、邮编等等 4.3 长字符串，非富文本 比如个人介绍等，过滤html标签（strip_tags），再加过滤sql注入函数(stripSql) 如果没有验证完全，或者不确定，可以使用mysql_escape_string()进行转义 4.4 富文本编辑器的长字符串内容 htmlspecialchars 采用统一函数或者类库验证过滤 4.5 这块详见附件 web安全规范 - 参数过滤 5、严禁使用register_global、extract函数，php配置中也不允许开启register_global 也不允许自己写代码，将外部变量全部变成内部变量，很多旧项目中就有 也不要开启magic_quotes，在需要的时候使用addslashes转义 二、报错信息 1、错误信息只能显示我们定义的对用户友好的内容，不允许显示与实际错误相关的内容 2、线上不允许开启报错，包括php.ini和程序中的display_errors 3、特别要注意，类似mysql_error等，只允许记log，不允许输出到页面 4、必须要记录日志，这是之后排查的唯一依据 5、日志不允许web直接访问到 6、更多报错相关信息，请参考内部博客 http://blog.geekman.vip/archives/27 三、数据存储 1、log文件不允许存储在web能访问的地方 2、cookie记录 2.1 必须设置httponly属性，防止js读取 2.2 cookie中不允许存储敏感数据，比如用户密码或者邮箱，手机号等 2.3 cookie内容必须添加签名，并存储，验证cookie的时候必须比对签名是否正确 3、数据库存储用户密码 3.1 不允许存储明文密码 3.2 必须添加盐值做散列 4、cookie、session等用户登录凭证，需要设置过期时间，防止被劫持之后，一直有效 5、注意加密算法和编码、散列的区别 不要误拿编码做加密（base64、urlencode等等） 不要使用自己编写的加密算法，采用成熟的高安全性算法 6、日志文件中，不允许记录密码、银行账号等敏感数据 四、数据签名 1、签名做法可以参考内部博客 http://blog.geekman.vip/archives/46 2、cookie存储需要签名 3、写接口必须加签名 4、敏感的读数据接口也必须添加签名验证，比如用户邮寄地址等 五、防暴力破解 1、用户登录等危险操作必须考虑暴力破解的情况 2、连续错误次数达到一定次数，则需要一个封禁时间 3、同一个ip同时对多个账号多次尝试也需要处理 4、发现有人暴力破解的时候，需要有报警机制，比如邮件、短信等 六、业务逻辑bug 1、发布的时候，进行了相应的过滤，但是编辑的时候未处理，也会导致bug 2、修改密码的时候，不进行验证，直接修改 3、购买商品的时候，价格直接通过参数传递结算 4、找回密码的时候，通过安全问题来验证，但是安全问题可以在登陆的时候直接修改 5、这些业务逻辑的bug，需要在需求、开发阶段就要多想想，特别是一些比较危险的操作 七、越权访问 1、所有后台、管理员操作的地方必须要经过权限验证 2、所有验证必须是通过服务端验证，不允许采用js隐藏，不显示按钮等来完成 3、每次都必须验证，不要指望在入口那边验证过了，操作的时候就可以不验证 4、权限验证，不要寄希望与链接、入口别人不知道，浏览器插件、搜索引擎，都有可能泄露 5、特别要注意调用接口的地方，不要遗漏 6、所有操作，都必须想想，这是不是一个所有人都可以任意访问的资源，如果不是，都需要权限验证 八、服务器安全 1、mysql资源 1.1 除非特殊申请，否则主库增删改查权限，从库查权限 1.2 给定权限的时候，必须限制ip，一般是内网固定某台 2、web服务 不允许使用root账号启动，比如apache等（我们的云主机上有见过root启动的） 不要安装不用的扩展，很多扩展是有高危漏洞的 3、redis、memcache资源 需要绑定ip，一般是内网 也可设置加账号密码访问 4、严禁rm -rf命令，同学的同事有过rm -rf之后，损失一个亿的教训 5、程序源码被直接显示出来 解析不当+程序员操作不当，导致.bak文件等直接源码显示出来 6、.svn文件夹等，直接可以遍历扫描 7、web访问目录层级,web不允许直接访问到项目代码根目录 /项目代码根目录/webroot/ 九、文件上传 1、上传文件的存储目录，不允许给执行权限【最重要】 2、上传图片采用其他域名访问，与web服务域名分开 3、文件扩展名白名单过滤 4、存储文件名必须系统生成，不允许用户自定义 5、想了解更多，可以参考内部博客 http://blog.geekman.vip/archives/301 十、不要调用系统命令 1、不要在web服务中调用shell命令，比如exec,system,eval之类的 2、实在要用，shell命令的参数不要是通过web参数带过来的，否则很容易导致系统被攻破 十一、测试环境 1、重要项目，必须有搭建测试环境（可以在本地搭建） 2、测试环境的数据库、memcache等资源也必须是用的测试的 3、不要把调试后门给上传到了线上，因为不知道哪天调试后门就会被人非法访问了 不要觉得你这个链接从来没公布出去别人不知道，有个东西叫浏览器插件，还有个东西叫抓包 十二、跳转链接 1、登陆等callback页面，必须要对callback后的链接进行验证 否则给用户发了一个育儿网的链接，结果用户登陆之后跳到一个恶意网站，在恶意网站提示用户账户密码错误，请重新输入，然后就会导致用户账户密码被盗 2、进行有根据用户的referer来进行跳转的，referer中的链接也需要验证，可以随意伪造
分类： web安全
【web安全规范】- 1、人为疏忽
编 写：袁 亮 时 间：2015-09-30 说 明：web安全规范 - 1、人为疏忽 一、公司代码 1、不管在职离职，都不允许将公司代码上传，比如github，各种网盘等 2、不允许在个人博客等公开文章中出现公司域名、服务器地址、服务器目录结构、账号密码等相关内容 二、密码安全 1、简易密码 不要设置像123456，password这种简单密码 具体的可以在abc.ci123.com后台中的密码安全监测中测试下，自己的密码是否安全 2、密码泄露 不要将自己的账号、密码、安全口令等记录在博客、公开网盘，或者私人邮箱等 不要将账号密码记录在公司后台等其他人能看到的地方 3、邮箱安全 请勿使用私人邮箱作为工作用 邮件中，不允许发送账号、密码，服务器秘钥等危险内容 定时更改企业邮箱密码 4、外部人员 不要将自己的账号或者保密资料发给外部人员 5、请不要将自己的账号密码，UKEY等给其他人用，包括公司同事 每个人的账号权限不一样，如果没有权限，请找直属领导申请相应权限 6、不允许设置万能账号、万能密码之类的东西 三、数据安全 1、请勿私自将公司数据（运营、统计、客户报价等等）在微信、QQ、博客等地方透露 2、后台数据导出，必须征得部门领导同意，请勿私自导出备份 3、技术人员不允许私自导出、备份公司数据库数据 四、后台、管理员操作越权 1、发现有后台不登陆即可访问，任何人员都有义务向部门领导反馈 2、请勿在公共电脑上，登陆后台并记住密码 3、技术人员不允许私自将后台权限验证的地方去除
【web安全】- xss注入攻击的总结
编 写：袁亮 时 间：2014-10-10 功 能：xss攻击的总结文档 一、xss注入攻击危害 1、cookie、session等劫持，任意登陆其他用户、管理员的账号，从而做一些非法操作，比如登陆后台操作等等 2、挂马、流量劫持，将正常访问我们站点的流量导到他们的网站，从而实现谋利等 3、记录用户的键盘输入，从而实现盗取账号密码等 4、弹出广告，篡改页面，引导用户输入账号密码等 5、用管理员权限，进行提权，比如上传一些webshell，进一步来提权控制服务器等 6、使用劫持的流量进行攻击等操作 二、防御措施 1、cookie设置的时候，设置为http only，除非没办法一定要给js读取，否则都设置为http only 2、外部参数都要过滤：get、post、cookie 3、数字型参数，一律使用intval转型 4、字符串：纯文字，不允许html、js等效果的，使用strip_tags过滤，绝大多数都可以防止 4.1 非编辑器的内容输入，基本上都可以采用该策略 4.2 编辑器的内容，产品允许的情况下，也可以这么用，指定strip_tags的第二个参数，只允许部分标签 5、字符串：允许html,但不允许脚本执行(编辑器内容) 5.1 完全避免是不可能的 5.2 针对一般性的注入进行防范，参考附件中的removeXss函数，还是会被绕过 5.3 去除了一些危险标签，以及几乎所有的js事件，可能会存在误判，可根据各项目情况，自行修改过滤标签数组 5.4 一般只针对富文本编辑器产生的内容处理，其他的采用上面的方法处理 6、采用html purifier来过滤所有的xss攻击（成本较高，特别重要的项目的部分输入才引入） 6.1 只看了大概介绍，没有具体研究，有兴趣的可以试下 总结：数字型支架intval，非编辑器产生的字符串基本都可以用strip_tags过滤，编辑器的可采用removeXss进行过滤。 三、其他工具 1、web自动扫描工具（360漏洞扫描） 2、360webscan.php（自动拦截记录get、post、cookie中的非法请求，会上传报告，记得关掉，易误伤） 3、XSSer 4、app检测：http://service.security.tencent.com/kingkong 四、通用后台登陆验证升级： 1、产生的登陆cookie设置为http only，防止因为其他站点的xss工具导致cookie被劫持 2、验证生成的秘钥与验证时候的ip与agent绑定，防止非法使用 3、登陆产生的秘钥存储在session中，过期失效
【web安全】- 文件上传漏洞
编 写：袁 亮 时 间：2014-10-27 说 明：文件上传、下载漏洞的研究 一、上传漏洞原理 1、用户上传了非法的文件 2、存储的目录有执行脚本权限，且非法文件能被解析 3、可以通过web方式访问该文件 二、上传验证攻防手段： 1、防御：客户端js坚持文件类型和大小是否合法 攻击：直接修改浏览器的js或者使用burpsuite等工具修改提交的数据 2、防御：服务端后缀名检测 攻击：直接修改脚本后缀名上传即可，后缀名判断采用白名单形式，不要用黑名单 2.1 结合服务器端的解析漏洞 2.2 IIS的解析漏洞：可以采用类似webshell.asp;test.jpg 的文件，会被IIS解析为webshell.asp 2.3 apache解析漏洞：webshell.php.rar.rar a.php.123 2.3.1 AddHandler php5-script .php 危险文件：test2.php.jpg 2.3.2 AddType application/x-httpd-php .jpg jpg也能作为脚本执行 2.3.3 配置了php2 php4等也作为脚本执行 2.4 nginx解析漏洞：/test.jpg/webshell.php （0.87版本以下） 2.5 windows下：webshell.asp_ webshell.asp.等形式，windows自动会把asp后面的去掉 2.6 linux下：webshell.php0x00.jpg 0x00在C里是终结符，会被截断为webshell.php 3、防御：服务端MIME类型检测 攻击：修改请求包中的Content-Type字段即可绕过 4、防御：服务端根据文件内容进行类型检测 4.1 文件头头检测，比如getimagesize等，检测的就是文件头不10个字节左右 4.2 文件加载测试，比如图片渲染，或者二次渲染 攻击：修改上传文件的内容 4.1 在正常的图片文件头之后，加入可执行脚本 4.2 使用GIMP工具，在图片的空白区域，填充代码，可以绕过渲染检测 三、上传之后攻击 1、服务器配置不当，导致webshell被执行 1.1 上传目录可执行 1.2 非法文件名被解析 2、程序不当，导致webshell执行 1.1 引用了上传的文件(很多开源的框架都有这种漏洞，比如UCenter的js.php等等) 1.2 直接使用了源文件的后缀名等，导致成功使用了解析漏洞，如果生成的文件都重命名了，那么文件名解析漏洞肯定不存在 3、得到webshell之后，基本上，可以说这个站点已经沦陷了，后面可以做的事情太多了 3.1 有个很出名的webshell叫中国菜刀，大家可以下过来玩下 四、安全防范 说明：具体看各种攻防手段，感觉要完全解决上传漏洞是件非常麻烦，而且有技术含量的事情 但是从本身的原理上来看，只要遵循规范，其实是一件很容易规避的问题(开源框架例外，太多不可控) 1、服务器方面： 1.1 【最重要】上传文件的目录，设置为不可执行（就算所有判断都没加，只要这点做了，基本上就成功了） 1.2 apache、nginx不要配置一些奇怪的解析 1.3 上传的图片可以采用统一的域名进行访问，不与web服务器一起 2、程序方面 2.1 根据文件头，判断文件类型，并采用白名单过滤，只允许有限几种类型 2.2 重写文件名，并且文件名与用户输入的数据无关 2.3 如果是图片的话，可以进行图片压缩等操作，一般来说，非法代码都会被干掉 五、容易遗漏的过滤 1、引用了富文本编辑器，但是没做任何更改，一般富文本编辑器会自带了上传功能，包括服务器端的，很多人会忘了该这个，从而导致webshell被上传执行 2、开源框架本身的有include一些生成文件的，这个只能多关注开源框架的一些最新安全消息，进行升级 六、文件下载 1、文件下载遵循一个原则，所有要下载的文件名，都不允许是通过参数传递进来的 2、将可下载的文件，通过后台等形式记录到数据库中，并给与编号 3、只允许根据编号来进行相应的文件下载 4、导出数据的，根据取到的数据库，生成文件下载需要防范的是sql注入等问题，与文件下载本身没什么管理，参考其他防范措施 附录： 1、在图片里写入一句话木马 copy /b tangwei.jpg+yijuhua.php tangweiyijuhua.jpg 2、二次渲染 就是重新生成图片，然后删除原图
【web安全】- sql注入的实战与防范
编 写：袁 亮
时 间：2014-10-24
说 明：sql注入的实战与防范
一、对m端知识目录下的程序进行注入：
1、结果：通过sqlmap将整个baike的数据库down下来了
2、代码有以下问题：
2.1 程序设置了报错开启输出
2.2 参数没有做过滤，大部分都是整型，intval下其实就可以解决
2.3 搜索功能的搜索值也没有做任何处理
2.4 妈妈经的后台，sadmin/sub下的所有程序都没有验证登陆
2.5 妈妈经后台的处理程序，对任何外部数据都没有处理，后台要是沦陷，轻易可以住人做任何事情
3、处理结果：
已经反馈给戴维杨，做相应的升级
二、英皇下载漏洞以及sql住人漏洞的利用：
1、结果：根据乌云上爆出的漏洞，将英皇那台服务器上的代码基本上都down下来了
根据其中的sql住人利用，使用sqlmap将其库拖成功
2、学到的东西：
2.1 sqlmap在住人rewrite的网址时，对rewrite网址中参数部分加一个*号即可正常住人，否则rewrite过的页面是住人不起来的
2.2 报错绝对要关掉
2.3 猜测程序目录等的时候，可以通过读/etc/passwd文件，知道服务器上有哪些账号，根据账号读取相应的/home/账号名/.bash_history 来读取历史操作
2.4 结合页面url，来猜测其中的一个文件，只要找对了一个文件名，就可以根据引用关系顺藤摸瓜，将其绝大多数代码搞定
三、openlogin服务器端安全升级：
1、上周对openlogin的客户端进行了安全升级，但是服务端很是很脆，上去看了下，拖库太轻松了，所以将其安全方面升级了下。
2、具体实现：
2.1 mysql_error不允许输出
2.2 openpassword加密，现在是直接输出的数据库中的md5值
password记录到cookie中的值为md5("实际密码").','.生成时候的时间戳.','.md5(时间戳+随机字符串)
使用cookie中的密码时候，必须保证前后两个都是32位的md5值，中间的时间戳不超过1星期，后面的MD5验证串正确
当用户的cookie被劫持的话，还是有可能被绕过
2.3 用户输入的用户名只能是4位小写字母加0到16位小写字母加数字
2.4 密码必须超过6位，必须有两种字符(大写字母、小写字母、数字、特殊字符)
2.5 密码不带入sql中进行查询，只根据账号取出来的密码进行字符串匹配是否相等，从而防止sql注入
2.6 所有的cookie不允许js读取
2.7 openlogindomain也做同样的升级处理
2.8 该目录下的其他数据库连接文件，全部引用ci123_safe.php文件，防止一般攻击（40多个文件，改的好蛋疼...）
四、防范要点：
1、对所有的外部数据都要过滤，判断($_GET,$_POST,$_COOKIE,$_SERVER等)，不要使用一些奇奇怪怪的数据接收方式，比如$_REQUEST,$GLOBALS['HTTP_RAW_POST_DATA']之类的，这个后面要审核代码就是个悲剧，容易漏掉
2、清楚的知道数据是什么格式，多少长度的，做相应的判断
3、90%以上的参数都是整型，直接intval处理
4、字符串型的，如果是特地格式的数据，直接用正则来判断：
4.1 手机号、ip地址、用户名、QQ号、邮编、邮箱、日期等等
4.2 这些的正则网上随便找找就一大堆，不要说不知道怎么写
5、富文本编辑器的的情况下，可以采用360的过滤，因为这些很难验证，我们可以采用他们做的这个来验证
6、千万不要开报错！！！页面里不能输出
7、数据库权限开通：master:增删改查，slave:select权限即可
五、攻击小技巧
1、利用搜索引擎找到有漏洞的页面：site:***.com inurl:?id=之类的
2、通过在参数后面加单引号或者and 1=1 ,and 1=2 来判断是否可注入
3、善于利用工具来做，然后看下工具生成的攻击log来学习
【web安全】- CSRF攻击的说明和理解
编 写：袁 亮 时 间：2014-10-14 功 能：CSRF攻击的说明和理解 一、介绍 1、跨站点请求伪造 2、不收集用户的cookie、不伪造cookie、session等验证信息，直接让用户使用有验证过的情况下去做一些请求，从而造成 破坏 二、大致原理 1、诱使用户访问一个有问题的页面A 2、该问题页面A中会发起一个隐藏需求，比如3、用户在访问该页面的时候，会以验证过权限的身份隐式的请求 4、可能会发起是post或者get请求，post稍麻烦点，get非常简单 4.1 隐藏一个自动提交的post表单，还可以发送到一个隐藏的iframe里，对用户完全透明 4.2 如果是用户自己的站点，ajax发起post请求 4.3 通过flash发起post请求 三、防范 1、重要操作，采用post请求，不要用get请求，get更容易伪造(删除、顶、点赞等) 2、慎用P3P头，因为这个会导致一些浏览器的cookie安全策略失效(img,iframe等请求本是不发送cookie过去的) 3、重要操作添加验证码(对用户不友好) 4、refer检查，易误伤(有些浏览器不发送refer，而且refer易伪造) 5、Anti CSRF Token验证 5.1 token放在表单中，不要放在链接中 5.2 session或者cookie中也存放一个token 5.3 token使用后需要释放，但需要注意多个页面待提交的问题，生成多个token来解决 5.4 如果存在xss漏洞的话，token就基本无效了 四、例子(让用户关注我的育儿微博账号) 1、让用户访问我的一个页面 1.1 可以是一个自己的网站 1.2 也可以随便找个有xss注入攻击的站点，比如在博客里插入一段危险代码 1.3 具体代码可以参考附件中的add_fans.php中的代码(非常简单的html加一行js) 2、用户访问时，会隐藏的提交了一个post请求 2.1 该请求对用户完全透明 2.2 不需要伪造用户的登陆信息，也不需要获取用户的登陆信息，完全绕过登陆验证环节 2.3 用户只要登陆了育儿网账户，就会自动关注我的微博账号 3、其他危险 3.1 通过这种方法，基本上，可以用用户的账号做任何操作(对我们网站现在的情况来说) 3.2 让访问的用户，自动发送一篇带有add_fans.php的博客，形成蠕虫病毒扩散(xss过滤不完成的话) 3.3 在扩散出去的这些用户中，还可以升级下add_fans.php的代码，比如让他们帮忙发广告、投票、评论等等