程序安全学习总结

安装程序的安全问题：

1. 存在默认帐号权限

默认帐号的用户名，密码都是在网络上公开的，很多初级的软件使用者有时忽略了这样的一个帐号的存在。这些默认的帐号，即便是权限很小的Guest帐号，也可以给被攻击者用来做很多事情。


2. 滥用Public

给予Web访问用户太多的权限，比如create procedure, 那么提交的Url里面就可能包括创建，并且执行procedure的命令。
另外还可以通过Database去访问Intranet的Web Server,通过DB的HTTP访问等。


3. 额外的管理代码，Demo代码或者测试代码，

这些额外的代码可能会被Google的爬虫所捕获到（比如：搜索login.jsp.bak），由于这些代码是不被编译执行的，所以源代码就被当成普通文字网页获取到了，采用特许的关键字搜索，就能获取到这样的页面，然后就知道某个主机的帐号，密码等。

另外这些代码可能设计的不是很好，有很多Hard Coding，所以容易暴露程序的地址，参数，逻辑等

这些代码最好放到其他的目录，以便用来刻录，不发布到生产环境中

如果某些文件的运行需要较高的权限，那么在安装完成后，立刻取消这些权限


4. 文件的权限设置

攻击者有目标系统的低等级权限以后，通过浏览各种其他文件，然后有可能获取应用的帐号和密码。 如果对某些配置文件有写的权限，那么可以修改配置。 另外很多安装后的Temp文件里面可能会含有安装密码。 所有不能认为只可读就是安全的。


5. Process的权限太高，比如有root权限

Process是指某些应用，这些应用如果被攻陷的话，由于其拥有root权限，那么就等于攻击者拥有了root权限

PL/SQL应用就是其中的一种，audit log的可读帐号，要和execute帐号一致，当其audit失效（暂时不明白是如何失效的）的时候，就能给用来干很多坏事， Database Role不能有connect和resource权限

Windows Service也是一样，他有相当高的权限。即便Service不在某台机器上，通过控制这些Service，然后采用其message就能控制远程机器。

SETUID是一种添加权限的Process，这种process被攻陷就更恐怖了

JAVA程序如果没有显示访问权限，那么可能会被用来浏览文件，然后找到password



6. 辅助Debug的代码演绎成后门程序

一般有详细配置，或者修改配置用的代码，帮攻击者熟悉了系统，获取了密码



7. 无用的备份代码，或者其他无用代码泄漏源代码，或者密码

*.bak,  *.sav. old等，泄漏源码，被google获取

有可能有些work目录也能被访问，这样的话，所有的源码都被暴露了。

另外还有一些data目录，用来做测试的，也被保留在site里面了，这样这些信息没有被保护好的话，也能被获取并攻击。



8. Unix的安全安装

采用最小必要权限， 用umask来确保继承正确权限， 采用特殊权限保护某些目录， 安装过程中要用到的权限在用完后设置取消，  临时文件如果可以的话放在memroy里面，用完就失效





数据验证安全问题：  85%的安全问题出在这里


1. 字符编码的安全问题

比如有些应用只对小写的文件名进行验证，非小写文件名则不进行验证而直接通过。绝对属于编码问题

A可能会有好几种方式%41, 0x20  0x34  0x31等， 程序接收这种编码后的字符串，可能会导致接受了攻击者的更多注入的代码，隐藏在这些编码后的字符串里面

所以对于接受URL或者参数的时候，尽量不要是编码后的，或者需要校验一下。

绕过验证

多个字符解析时候被当成了单一字符，也会造成安全验证被绕过 (xx>b)  (xx==1|x>b)   xx被替换成了1==1||x>b 后面就始终是ture，造成了绕过验证




2. 网络数据的问题

网络数据需要在Client和Server端同时验证， 服务端要假设所有的Client都是不怀好意的。 某些valid Session可能会被捕获，然后被利用来做攻击。


3. 溢出问题

由于c不进行边境检查，攻击者给输入参数传入一个很大的字符串，如果程序不自己校验边境，那么这字符串就被加载到内存里面了， 字符串里面可能会有另外一段script， 当当前方法执行完后，可能会被定为到攻击者的代码段，然后被实施了攻击。


4. 格式化String的问题


5. SQL的注入攻击

加入注释符号--，让后面的具体验证失效。 避免使用从客户端传入的字符串拼凑SQL， 一定要采用安全的预编译的方式

where userName='admin--' and password='xx'


6. XML的注入攻击

在portal dynamic XML generation package里面可以插入sql进行攻击


7. Script的注入攻击

在url里面添加<script>...</script> 的参数， 这段代码被记录到数据库， 当有人打开包含这段代码的页面的时候，我的script就在其机器上执行了。 对方可能是银行内部人员，这样我的scritp就有访问银行内部网站的权限了。


8. Shell的转义


9. 文件名的攻击

比如class文件访问的目录在classes以下， 但是程序通过  .来表示当前目录，  ..表示上层目录，夹杂在路径当中，导致相对目录为文件的暴露。 /WEB-INF/./web.xml 




CGI以及Web程序的攻击：

1.  通常的攻击方法：  
获取HTTP Header，并且假冒。  
在URL的Get或者Post数据里面添加自己的参数， 获取sessionId，假装是valid的client.
通过url参数猜测逻辑，
数据传入到server的时候，被intercept或者translate了
cookie或者session的泄漏，由于Browser的原因
有些网站禁止Browser查看源码的，这是徒劳的，因为如果采用一般的Telnet，那么可以bypass it.



2. Cookie Attack:

开始攻击之前需要进行一些资料收集的工作，比如主机名， 比如url：   各种名称能够反映出系统的架构，或者是逻辑分布等

db1.example.com 代表的是一个Database，那么就可能会被确认了攻击目标

此外还有版本号， cookie里面的值， 隐藏字段等



3. Session Attack:

关键就是根据各种方法比如监听URL， 查找本地文件，或者是History URL，等找到sessionID， 然后进行连接

此外，sessionID还可能