安全脚本程序的编写 V1.0

我看到过很多的对脚本的加密方法，都很不错，有的是专门的加密软件，有的是通过一些技巧加上利用语言的特性进行加
密的，例如随机生成一个
密匙，把密匙放在"不可见的"地方，通过一些算法对脚本进行加解密，就是由于某些系统漏洞导致你的脚本源代码泄漏，
也无济于事。
4 .实例说明
下面这个例子是在网上经常被提到的，这是个非常经典的例子，所以在这里通过这个实例告诉大家可能存在的危险。
问题描述：
　　大部分网站把密码放到数据库中，在登陆验证中用以下sql,(以asp为例） 
sql="select * from user where username='"&username&"'and pass='"& pass &'" 
　　此时，您只要根据sql构造一个特殊的用户名和密码，如：ben' or '1'='1 
就可以进入本来你没有特权的页面。再来看看上面那个语句吧： 
sql="select * from user where username='"&username&"'and pass='"& pass&'" 
　　此时，您只要根据sql构造一个特殊的用户名和密码，如：ben' or '1'='1 这样,程序将会变成这样: 
sql="select*from username where
username="&ben'or'1'=1&"and pass="&pass&" or 是一个逻辑运算符,作用是在判断两个条件的时候,只要其中一个条件成
立,那么等式
将会成立.而在语言中,是以1来代表真的(成立).那么在这行语句中,原语句的"and"验证将不再继续,而因为"1=1"和"or"令
语句返回为真值.。
　　另外我们也可以构造以下的用户名： 
username='aa' or username<>'aa'
pass='aa' or pass<>'aa'
　　相应的在浏览器端的用户名框内写入：aa' or username<>'aa 口令框内写入：aa' or pass<>'aa,注意这两个字符串
两头是没有'的。这
样就可以成功的骗过系统而进入。
具体实施是这样的，首先我会到注册的地方去收集信息，了解尽可能多的信息，例如目标数据库中都有用户的什么样的信
息，随便的填写信息然后
提交，当你要注册的用户名被注册的是有系统会提示你已被注册，有的网站做的更好的，就是他们专门给你设置的检测是
否有已经被注册的功能，
通过这样就会非常容易的找到目标--那个提示已被注册的用户，让后你在这个注册页里填写一些特殊的字符，如'，/，,等
字符看系统如何提示，以
证明程序员是否注意到了应该过滤字符或懂得是否应该过滤那些字符，在这页进行尝试是因为有的网站在登录的时候他会
记录你的ip地址，当然你
也可以找一个比你直接登录要快的代理服务器来做跳板。后面你要做的就是察看登录页的html源代码，看看是否有在客户
端的字符过滤，看看这个
程序员是用什么风格来编写程序，尽可能多的了解程序编写风格，这对你以后的某些判断有好处。如果有在客户端的过滤
也不怕，你要搞清是什么
样的过滤，能不能对攻击造成威胁，不要一看有过滤就害怕，可以尝试着用别的方法绕，就是使用自己精心打造的独立脚
本，进行攻击。然后你要
看看form的action中的url是否可以直接提交，在浏览器地址栏里直接提交，看看返回什么，是否有来路检测。还有很多细
小的地方，你也应该可
以注意到，例如那些地方程序员的整体的编写风格是什么，变量名定义的风格是什么等等，这个会帮我们"猜"到很多东
西。还有别的其他什么，我
也记不太清楚了，临场发挥吧。通过这些了解我们有如下几种可能：
1.那个程序员非常善良相信全世界都是好人，什么都没做，根本没有任何检测机制，我们直接用username='aa' or 
username<>'aa'，
pass='aa' or pass<>'aa'就可以搞定，现在这么善良的人少啦，可是你要是有耐心，找到这种人还是不难的。
2.这个程序员可能听别人提起过一些安全问题，毕竟现在这个那里都有人说，很多书中都有提及，但是做得不够好，他只
进行了简单的输入过滤。
过滤有两种方式，一种是在客户端的过滤，一种是在服务器端的过滤。现在很多的程序员考虑到再服务器端进行过滤可能
给服务器造成更多的负荷
，会把检测过程放在客户端。如果他在服务器端没做任何事情，那么还是可以对其进行攻击的，我可以将这个登录页的源
代码COPY下来，然后自
己建立一个文件把这些代码PASTE进去，再对这个文件进行进一步的深加工，去掉原来页的过滤机制，或者直接将攻击代码
写到这个文件中去，然
后将form中的action中的地址改成绝对地址，也就是将文件名改成"http://www.target.com/targer.php"这样，然后就可
以提交啦。但是如
果服务器端加上了"来路检测"，你就白玩了。如果这样还是不行，我再换一种方法，在浏览器的地址栏里用？来输入参
数，就好像
"http://www.targer.com/targer.php?username='aa' or username<>'aa'&pass='aa' or pass<>'aa' "然后敲回车吧，其
实应该先
尝试这种方法因为这用方法更简单，防护起来也很简单，这种提交方式不是post 而是get ，只要服务器端程序检测你的提
交方法，就可以kill掉这
个阴谋。如果单纯的只检测了"来路"，还是不太安全的，可以先正确的提交一次，在提交过程中马上停止，就是保存这个
环境，然后再构造请求。
（我做过几次试验得到的结果都不太一样，应该是和终止的时机有关，欢迎大家来交流）。
3.一个很出色的程序员，安全意识非常高，他在服务器端做了如下检测：检测提交的方法；检测提交的"来路"；检测提交
内容的长度；全面检测提
交内容，这样我们就很难通过上面的方法对其进行攻击，那到保密的资料就已经不太可能了（如果各位还有什么好的办
法，请一定来信告诉小弟，
小弟在这里先谢了）。但是我还想说的是攻击并不代表是非要入侵进去，拿到某些东西才叫入侵，对你的机器进行破坏也
叫入侵啊，例如提交一些
错误的请求，脚本解释程序就会非常规矩的给你返回错误信息，最浅显的后果就是暴露物理路经，有的时候一些特殊的请
求会使web服务宕掉，这
些个我认为绝对是属于攻击，绝对是危害，也许你认为暴露物理路径没有什么，是在单独看来没有什么，但要是在一个有
计划的攻击里，这个就会
发挥很多作用，那时你可能还会莫名为什么他们找到了我的文件呢。也许有人认为这个是脚本解释程序的bug，也许有的
是，但是返回错误信息绝
对不是脚本解释程序的错误，这个是每个解释程序都要做到的，在我看来这个应该是还是程序员的问题，程序员没有做好
对错误的处理。每一本教
你如何编写程序的书籍里基本都会有错误处理之类的章节，并且每种语言基本都有错误处理函数和方法，只不过你没有想
到罢了。至于究竟要怎么
处理那就要看你对cgi程序安全的熟悉程度了，那就要看你对这种脚本语言的特性熟悉多少了，说到底就是经验，唯一的办
法就是多看多写多想多
交流。
4.非常优秀的程序员，以上那些做的都非常好（也许就是你啊，毕竟不难嘛，加上很少的代码就可以了），怎么办？？怎
么办？！怎么办！！在一
旁偷偷的佩服吧！哈哈。
5. 其它注意事项：思路和方法
指导思想：
I.严格控制程序与用户交互的途径
II.严格控制程序与用户交互的内容
III.尽可能好的保护我们控制
基本思路：
I.为没一个功能写一个独立的程序，程序页
II.尽可能少的让客户了解你的服务器端信息
III.不要用"客户应该这么写"这个思路想问题
IV.尽可能多的想到不可能发生的事情
基本方法：
尽可能多的控制交互：
I.检测提交的方法，就是控制他的post还是get；
II.检测提交的"来路"，就是检测一个环境变量HTTP_REFERER；
III.检测提交内容的长度；
IV全面检测提交内容；
积极-消极防护：
I.尽可能多的错误处理，例如当检测到了不正确的输入时，应该怎么做，是强制返回，还是发出警告；
II.充分发挥日志功用，例如在你检测到了不正确的提交时，就记录下客户端的信息，例如IP，系统配置，请求等等，毕竟
现在是技术飞跃的时代，
不能保证可以想到每一种可能，这也是我在这篇文章里不止一次提到"尽可能"这个词的原因。充分的日志记录不全是为了
抓住入侵者（如果入侵者
使用了跳板，记录了IP也是没有用的），更重要的是为了能发现问题的所在，找到问题，改正问题，亡羊补牢，这个才是
最重要的。
III.充分发挥你的想象力，用一种入侵者的思想考虑问题，用一种另类的思想考虑问题，尽可能想到不可能发生的事，把
问题扼杀在萌芽里。
我们xundi哥说的好：掌握方法！！！现在脚本语言层出不穷，asp，perl，php，jsp等等，基本不可能精通每一种，（也
许你厉害，都能精通，
我比较呆，会一个就不错啦），但是要是掌握了方法就不同了啊，各位网络的精英举一反三触类旁通，肯定是优秀的不得
了。我写脚本一共也没多
少天，写这个东西我知道肯定是班门弄斧了，错误之处还请各位大虾抱着挽救和帮助的精神，告知小弟（方式、方法、态
度不限），小弟我在这里
先谢了。写这个东西，我只是想说说小弟的一些小的心得，与大家共勉，我想告诉大家的就是"领会精神"，嘿嘿，"领会精
神"。大家要是有什么好
的方法，希望不要保留，充分发挥网络的自用共享，拿出来，大家交流交流，不胜感激。
袭来的，这种东西小弟不敢自己写（嘿嘿，实际还有不少懒的成分，哈哈），希望大家不要见怪。

最新评论