安装程序的安全问题：
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还可能
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还可能
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
