编 写：袁 亮 时 间：2015-11-20 说 明：https的使用注意事项 一、全部https的优缺点以及选择 1、优点 1.1 安全性高 2、缺点 2.2 用户访问会变慢，特别是第一次访问（需要下载证书） 2.2 开发成本较高，https页面的所有资源都必须是https资源 2.3 统计代码不能使用，大部分统计代码都不提供https版本 2.4 服务器端的负载也会变高 3、其他网站参考 3.1 百度、淘宝等很多二级域名也不是https 3.2 京东大部分都不是https 4、结论 只针对安全级别高的几个页面采用https即可，不需要整个域名都使用https 二、开发过程注意事项 1、静态资源都必须是https 1.1 js等请求，浏览器直接会阻止http的请求 1.2 图片请求，http的不阻止，但是会报warning错误 1.3 为兼容http和https同时访问，可以写//***.ci123.com/****，会自动根据当前的访问协议加上http或者https 2、ajax请求 2.1 ajax请求也必须是同协议的，否则将跨域，不能访问 2.2 jsonp可以解决这个问题，但最好不要这么做 3、核心cookie可以设置为仅https访问 3.1 淘宝中的skt，对应的应该是一个sessionId，就是仅https的 3.2 这个设置要小心，因为该cookie在http中是访问不到的 3.3 可以防止cookie被劫持，一般用与session 3.4 用的不多 4、关键地方，只配置https，不允许http访问 4.1 防止用户被引导到http请求中，然后输入了敏感信息 三、安全问题 1、证书伪造：浏览器有提示 2、引导到http请求，然后盗取 四、其他 1、https请求可以被缓存 附录： 1、HTTPS连接的前几毫秒发生了什么 http://blog.jobbole.com/48369/ 2、与HTTP有什么区别？HTTPS的七个误解 http://www.chinaz.com/web/2015/0320/391752.shtml 3、HTTPS那些事（一）HTTPS原理 http://www.guokr.com/post/114121/ 日志转载：HTTPS那些事（二）SSL证书 http://www.guokr.com/post/116169/ HTTPS那些事（三）攻击实例与防御 http://www.guokr.com/blog/148613/
作者： 暗夜御林
jquery – 事件绑定的不同写法
编 写：袁 亮
时 间：2015-11-16
说 明：jquery事件绑定
一、作用
1、将html显示与js动态交互分离，不在html中写一堆的onclick等js
2、简化代码，统一处理，防止遗漏以及重复写，比如ajax请求等
3、结构清晰，分层，html，css，js等独立
二、如何绑定事件
1、bind：向匹配元素添加一个或多个事件处理器
1.1 所有jquery版本均支持，但1.7版本后，推荐使用on
1.2 只能对已经存在的元素进行事件绑定
1.3 了解即可，不使用
2、live:向当前或未来的匹配元素添加一个或多个事件处理器
2.1 jquery 1.9版本以上，已经删除
2.2 使用on来代替
3、delegate：为指定的元素（被选元素的子元素）添加一个或多个事件处理程序，并规定当这些事件发生时运行的函数。使用 delegate() 方法的事件处理程序适用于当前或未来的元素（比如由脚本创建的新元素）
3.1 jquery 1.4以上版本支持
3.2 1.7以下版本的时候可以考虑使用，旧项目，新项目使用不要使用
4、on【重点】:为指定的元素,添加一个或多个事件处理程序，并规定当这些事件发生时运行的函数。使用 on() 方法的事件处理程序适用于当前或未来的元素（比如由脚本创建的新元素）
4.1 jquery 1.7以上版本支持
4.2 尽量使用这个，不要使用其他三种绑定
三、简单例子
$("选择器").on({
click:function(){
console.log("我是"+$(this));
console.log("点击触发");
},
mouseout:function(){
console.log("我是"+$(this));
console.log("鼠标触发");
}
},"子选择器(可选)");
四、常见问题(1.72版本jquery下测试)
1、元素后加载，事件绑定不成功
1.1 示范代码
<code>
<div class="test">你好</div>
<script type="text/javascript">
$(function(){
//a标签事件绑定
$(".test a").on({
click:function(){
console.log("click");
}
});
//后加载生成dom节点
$(".test").prepend("<a>测试连接</a><hr>");
});
</script>
</code>
1.2 因为a标签是后加载的元素，在绑定事件的时候，dom数上还没有该元素，因此绑定失败
2、解决办法1
2.1 事件绑定在已经存在的父元素上，匹配选择器是否符合
2.2 示例代码
<code>
<div class="test">你好</div>
<script type="text/javascript">
$(function(){
//后加载生成dom节点
$(".test").prepend("<a>测试连接</a><hr>");
//a标签事件绑定
$(".test").on({
click:function(){
console.log("click");
}
},"a");
});
</script>
</code>
2.3 优点：绑定事件与处理逻辑脱离，代码更简单易懂
2.4 缺点：需要注意选择器必须是已经存在的节点，子选择器可以是后加载的元素，不清楚的话，可以直接绑定在document上
iphone下，会出问题，元素需要添加cursor: pointer;样式，手机使用，不采用这个
3、解决办法2
3.1 在元素加载后，执行绑定函数
3.2 实例代码
<code>
<div class="test">你好</div>
<script type="text/javascript">
$(function(){
$(".test").prepend("<a>测试连接</a><hr>");
$(".test a").on({
click:function(){
console.log("click");
}
});
});
</script>
</code>
3.3 优点：各种情况都兼容，不会出现绑定失败
3.4 缺点：代码可能不是那么好看，绑定事件混在了处理逻辑中
五、使用建议
1、使用1.7以上版本jquery，2.0以下（不兼容ie8及以下版本）
2、绑定事件均使用on来绑定，不要使用其他的
3、对于后加载元素，在加载完成之后进行事件绑定，避免兼容性问题
六、原理，额外拓展，dom树结构（了解即可）
1、可以使用off来取消事件绑定
2、可以使用.one，只绑定一次，触发之后就取消绑定
3、页面dom数结构
4、事件如何冒泡
附参考文档：
1、浅谈Jquery中的bind(),live(),delegate(),on()绑定事件方式
2、jQuery三种事件绑定方式.bind(),.live(),.delegate()
【svn入门】- 1、初次使用
编 写：袁 亮
时 间：2015-11-02
说 明：从未接触过svn的人，5分钟内学会简单使用svn
一、获取svn地址
1、发送邮件到cjy@corp-ci.com，告知项目名，申请获取svn地址
例如：http://****/demo/
2、如果没有svn账号的，也一并邮件中申请
二、windows中开始使用
1、下载TortoiseSVN安装
2、在需要使用svn的文件目录上右击，选择SVN CheckOut
3、从svn控制中心，更新最新的程序到本地
4、新增的文件，添加到版本库中
5、将改动提交到svn控制中心（新增或者修改都需要做这步操作）
三、linux种开始使用
1、进入到项目开发目录 cd demo/
2、从版本库中checkout下来
3、从svn控制中心更新最新版本
3、将新文件加入到svn中
4、将改动过的内容提交到svn版本控制中心
四、常用命令使用
1、【svn入门】- 2、常用命令及练习
2、pdf版本下载：【svn入门】- 初次使用
【web安全规范】 – 2、基本安全防御
编 写：袁 亮 时 间：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安全规范】- 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、技术人员不允许私自将后台权限验证的地方去除
php发送邮件的相关知识
编 写：袁 亮 时 间：2015-07-28 说 明：php发送邮件的相关知识 一、什么时候需要用到？ 1、系统监控，应用监控报警 2、相应的项目统计 3、用户注册、重置密码 4、发送推广内容（现在很少） 5、给用户的正式通知 二、php中发送邮件的方式 1、使用封装好的PHPMailer类发送【常用】 网上下载相应的类文件即可phpmailer 2、使用smtp类发送 与PHPMailer类似 3、PEAR::Net_SMTP组件 需要引用pear类库中的Net/SMTP.php和Mail/mime.php，服务器上没有的话，直接下载也可以 据说挺好用的，很强大，没用过，可以尝试下 4、内置函数mail php需要安装正在运行的邮件系统，了解即可，平时不用 5、popen管道形式发送 需要配置邮件服务器，了解即可，我也没用过 三、PHPMailer简单demo IsSMTP();//使用smtp协议 $mail->SMTPDebug = false; $mail->Host = "smtp.163.com"; //使用哪个smtp服务器，在对应的邮件设置里找SMTP服务器 $mail->SMTPAuth = true; //需要认证，必选，基本没有不认证的了 $mail->Username = "ci123_demo"; //邮箱账号，不需要@什么的，需要在邮箱里开启smtp服务，否则失败 $mail->Password = "nymqjctyjlykkfpt"; //开启smtp服务的时候系统自动设置的密码(163是这样) $mail->CharSet = "UTF-8";//编码设置 $mail->From = "ci123_demo@163.com";//发件人完整邮箱地址 $mail->FromName = "育儿网";//发件人备注名，可以随意填写，方便自己看即可 //发送给谁，可以发给多个人，多次执行AddAddress，前面是邮箱地址，后面是备注 $mail->AddAddress('yuanliang@corp-ci.com', "袁亮"); $mail->AddCC('629036398@qq.com','暗夜御林');//抄送，暗送是BCC $mail->Subject = '邮件标题'; $content = '邮件测试内容'.date('Y-m-d H:i:s'); //$mail->Body = $content;//纯文本内容，不能发送html $mail->MsgHTML($content);//以html的形式发送，一般用这个，方便排版 if(!$mail->Send()){ echo $mail->ErrorInfo; die(); } echo 'succ'; die(); 四、PHPMailer注意事项 1、php需要支持sockets，大部分情况下都开启了，phpinfo查看Sockets Support 2、最常见的错误是需要开启smtp服务，到对应的邮箱里开启 smtp服务器地址 邮箱账号 授权密码，非邮箱登陆密码 3、需要发送html内容的，需要使用MsgHTML 4、发送失败的情况下，第一反应是看报错信息，而不是瞎猜 五、邮件发送的注意事项 1、限制 每个邮件服务器，都有限制邮件数量，163的限制比较少 出现莫名其妙收不到的情况，可以尝试换一个账号发，换一个账号收等来测试是哪方面有问题 2、内容过滤 垃圾内容过滤是邮件服务器最核心的功能，如果对用户发的时候，需要注意内容是否会被过滤，可以先拿自己的账号测试 3、发送附件 AddAttachment('文件绝对路径','附件名称'); 六、邮件协议 1、POP3 1.1 POP3允许用户从服务器上把邮件存储到本地主机（即自己的计算机）上,同时删除保存在邮件服务器上的邮件 1.2 POP3协议允许电子邮件客户端下载服务器上的邮件，但是在客户端的操作（如移动邮件、标记已读等），不会反馈到服务器上 比如通过客户端收取了邮箱中的3封邮件并移动到其他文件夹，邮箱服务器上的这些邮件是没有同时被移动的 2、IMAP 2.1 交互式邮件存取协议，它是跟POP3类似邮件访问标准协议之一 2.2 IMAP提供webmail 与电子邮件客户端之间的双向通信，客户端的操作都会反馈到服务器上， 对邮件进行的操作，服务器上的邮件也会做相应的动作 2.3 IMAP像POP3那样提供了方便的邮件下载服务，让用户能进行离线阅读 3、SMTP 3.1 简单邮件传输协议；它是一组用于从源地址到目的地址传输邮件的规范，通过它来控制邮件的中转方式 3.2 SMTP认证，就是要求必须在提供了账户名和密码之后才可以登录 SMTP 服务器，现在已经没有不需要认证的了，除非自己搭 3.3 发送邮件，必须是开的这个服务 附录： http://www.w3school.com.cn/php/php_ref_mail.asp http://blog.csdn.net/heiyeshuwu/article/details/458170 http://blog.csdn.net/rainday0310/article/details/6281936 http://help.163.com/09/1223/14/5R7P6CJ600753VB8.html
php序列化对象导致的错误
编 写：袁 亮 时 间：2014-04-11 说 明：序列化对象导致的错误 一、问题描述 在迁移blogadmin项目的时候遇到了一个报错：(迁移前php版本：5.2.6、迁移后php版本：5.3.7) Fatal error: PostsController::index(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "Information" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition 二、解决过程 1、根据报错信息搜索，查找到文档：http://www.php.net/manual/zh/language.oop5.serialization.php 2、按文档里的说明，结合程序，出现问题的原因是： a、程序中，会把对象存储会话中(session，session会调用php的serialize函数序列化对象) b、在新的页面中，程序从session中，取出数据，并自行调用unserialize函数，反序列化对象，并且正常使用对象 c、以上要正常使用，必须保证对象所对应的类定义要在unserialize之前，否则反序列化出来的对象会有缺失，从而导致错误 d、一般情况下，调整session_start和引用类定义文件的顺序即可 3、根据上述信息，调试程序，发现调用对象的时候，类已经定义，而且类定义的引用在session_start之前 4、经查，发现是该服务器的php配置中，自动开启了session_start，导致session_start永远在类定义前，从而导致错误发生 5、修改php配置，并重启apache即可
【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来学习