系统管理方面的安全性考虑转载的.doc

系统管理方面的安全性考虑 转载的目录一、系统管理方面的安全性考虑.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、网站的错误信息必须经过处理后再输出一个网站，安全问题可能从多方面而来。光是任何一方面，都不可能保证绝对的安全。一个安全的网站，必须要各方面配合才能打造出来。一、系统管理方面的安全性考虑1、首当其冲的是服务器的安全服务器本身如果被人入侵了，你的网站系统再安全，那也没有任何作用。记得要关闭所有没有使用的端口。要设置复杂的密码，关闭没有使用的账户。2、其次是FTP或者远程管理等的帐号安全如果人家破解了你的FTP或者远程管理权限，那也就等于窗户开给人家怕，那家里的东西自然是随便拿了。3、应用服务器的安全性。3.1、Jboss安全加固(一)、前言：Jboss默认安装以后，会默认打开，显示如下：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.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的内容：粗体为添加屏蔽符号：！-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、2、3、4、5、测试结果：保证上述的服务都已关闭4、数据库的安全性设置数据库只有应用服务器才能连接。其他外部的机器一概不能连接。设置复杂的密码。(1)修改mysql的监听地址：默认mysql是监控所有的ip地址，也就是，为了安全考虑，我们也许只要mysql监控本地地址就好了。那么可以只要修改/etc/init.d/mysqld文件，在start部分找到类似下面这行$bindir/mysqld_safe-defaults-file=/etc/f-datadir=$datadir-pid-file=$pid_file/dev/null 2&1修改成下面的这个样子$bindir/mysqld_safe-defaults-file=/etc/f-datadir=$datadir-pid-file=$pid_file-bind-address=/dev/null 2&1注意：对于绑定地址这个参数不要加在 defaults-file参数前面，否则mysql会启动不了，并给出下面的错误：051025 9：57：27ERROR/usr/libexec/mysqld：unknown variabledefaults-file=/etc/f所以我们把 defaults-file=参数放在最前面。或者你可以在/etc/f的mysqld段加入bind-address=这样一行。重启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 ajump stationfor the malicious script sent by the attacker,to return to the victims browser,as if it is legitimate.)。无论如何，由于用户是在使用这个特定的网站，而且是这个网站的直接返回，因此可以认为是这个网站的安全漏洞。2.这个怀有恶意的链接由攻击者生成，可以包含在攻击者自己维护的网站中。这个链接攻击者也可以通过发送email的方式发送给受害人。3.由于用户输入是作为form的字段值，可以知道这串恶意代码从什么地方来的，4.各种浏览器实现的不一样，有时候在这种浏览器上没有问题，但是换一种浏览器就会有问题。攻击方法：写一个链接：参数值为：SCRIPT document.location=/SCRIPT这样，当服务器返回时，上面这串脚本将自动执行，将本地的Cookie发现指定的URL，用户资料泄露了。根本原因：1.没有对输入进行约束，没有对输出进行编码2.没有严格区分数据和代码解决方式：1.加强对参数的校验：一定要做，大量的漏洞都是针对参数未作校验引出很多攻击手法(会有如何检查参数的单独说明)使用时机：我尝试在各种不同网站寻找XSS漏洞，baidu,,,等等。结果，我发现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访问时，则非常危险：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)；elsewindow.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=textclass=Seachname=wvalue=XXX/OK，可以开始做文章了，我们将XXX替换为：abc/script alert(haha)/script ahref=，返回的HTML代码如下：input type=textclass=Seachname=wvalue=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=/SCRIPT SCRIPT alert(XSS)；/SCRIPT iframe src=INPUT TYPE=IMAGESRC=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/javascriptalert(XSS)；/STYLE STYLE type=text/cssBODYbackground：url(javascript：alert(XSS)/STYLE?=SCRIPT alert(XSS)/SCRIPT?A HREF=javascript：document.location=XSS/A IMG SRC=javascript：alert(XSS)EMBED SRC=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=a4.python的cgi.escape函数：def escape(s,quote=None)：Replace special characters&,andto 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 s5.ASP中的Server.HTMLEncode：%=Server.HTMLEncode(The paragraph tag：P)%6.ASP.NET的Server.HtmlEncode及Server.UrlEncode：String TestString=This is aTest String.；String EncodedString=Server.HtmlEncode(TestString)；Server.UrlEncode(Request.Url.ToString()；7.PHP的htmlspecialchars方法：?php$new=htmlspecialchars(a href=testTest/a,ENT_QUOTES)；echo$new；/a href=testTest/a?8.JAVA中的.URLEncode.encode：String mytext=.URLEncoder.encode(中国,utf-8)；9.有些网站使用过滤javascript关键字的办法来防止XSS，其实是很不明智的，因为XSS有时候根本就不需要javascript关键字或者对javascript关键字进行格式变化来躲过过滤。10.为所有的标记属性加上双引号。应该说这也不是万全之策，只是在转义了双引号的前提下的一道安全保障。比如：不加双引号时，onclick被执行了：a href=onclick=javascrpt：alert(haha)加上了双引号，onclick不会被执行：a href=11.将数据插入到innerText属性中，脚本将不会被执行。如果是innerHTML属性，则必须确保输入是安全的。如ASP.NET中：%Page Language=C#AutoEventWireup=true%html body span id=Welcome1runat=server/span span id=Welcome2runat=server/span/body/html script runat=serverprivate 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只