北京  ■ 深圳 ■ 上海  ■ 成都  ■ 重庆  ■ 浙江
经过数据恢复工程师的努力研究,已搞清楚了XFS文件系统的结构层。如果有基于XFS的NAS或LINUX数据出现问题,已有很大把握了。基于XFS数据恢复的软件已经完工。
站 内 搜 索
    
热 点 文 章
PC3000使用说明
关于硬盘坏道(绝对有收获) 
pc3000译文
U盘故障的详细维修方法! 
硬盘零磁道与分区表的修复
pc3000处理常见故障的一些方
推 荐 文 章
Hrt修复磁盘缺陷
pc3000处理常见故障的一些方
硬盘容量限制问题的形成以及
关于硬盘坏道(绝对有收获) 
20个美钻维修心德(1.22版)
Disk Genius V2.0 Beta 0219
FUJITSU盘故障表现
FUJ维修资料
最 新 文 章
北京理工大学
某数据恢复公司
捌捌国际
北京梁先生
吉林延边
山西刘先生
北京张先生
HP公司
联 系 我 们
北京北亚数据恢复中心
地址:北京市海淀区学院南路68号吉安大厦C座(汇智楼)528室
电话:(010)51280825
手机:13522617215 (张先生)
电子邮件:zymail@vip.sina.com
QQ:34000588(请叙述理由)
您现在的位置:

首页>>数据恢复文章>>正文

服务器反黑全集 网站服务器超级安全配置

作者: 来源: 日期:2008-04-28 17:29:03  点击次数:

不够黑客资格的人渣黑了,搞的数据库也没有了。 
方案四 
1、ASP/SQL语句注入:在多都是利用网页没有对提交的数据进行过滤而直接带入数据库! 
防:注入语句大多有如下字符:’ , % & = ; > < 来构成SQL语句! 
注意:我们要作的是对写入数据库中的每一个字段都要作过滤!是每一个,千万不怕麻烦!提供如下过滤语句! 
’**************************************************** 
if instr(accountname,"’")<>0 or instr(accountname,";")<>0 or instr(accountname,"&")<>0 or instr(accountname,">")<>0 or instr(accountname,",")<>0 or instr(accountname,"=")<>0 or instr(accountname,"%")<>0 then 
response.write "" 
response.end 
end if 
’**************************************************** 
把accountname改成需要过滤字段就行了!有多个字段就要多少个如上的判断语句! 
2、异地表单提交!(某此人用来突破原网页的种种限制) 
防:禁止异地表单提交!在你的数据库连接文件(conn.asp)加入如下判断语句! 
******************************************************  方案五 
编写安全的ASP代码 
发帖子的目的是为了大家讨论与研究。。。 
ASP中数据库的安全是一个很严肃的问题。很多代码的编写者意识到了这类问题,并且小心翼翼地对他们认为有问题的地方做了补救,但常见的情况是要么没有穷尽所有的可疑地点,要么这种补救逻辑上有误。对于一个耐心且嗅觉灵敏的攻击者来说,这种意义上的补救措施和没有任何补救措施没有本质上区别。 
下面罗列的是一些可能出现的问题:有些是常见易犯的错误,有些根本就是逻辑上有问题。看看你是不是也这样写过?对于攻击者而言,倒着看这些东西,应该对寻找漏洞有点帮助,更为完整一点的检测方法,请等我的关于黑/白盒分析和自动化测试文章。 
一、令人疑惑的过滤方式 
典型例子是不管不顾地对所有的输入变量都去掉单引号,或者是把单引号替换成合法的两个单引号,例如: 
id = replace(request.querystring("id"), "", "") 
str = replace(request("someinput"), "", "") 
现在很明了的是,第一个做法很有可能是错误的。因为引起SQL Injection的不总是单引号,再扩大一点,引起问题的不是任何单独的符号,这样子的过滤,有些冤枉单引号了。正确的利用注入,重要的一点是闭合前面的一句SQL查询语句——往往是得先正确地闭合前面一个条件,因为我们可能会在同一句里面引入新的条件,补救措施只要破坏注入条件应该就可以了,但是考虑到其复杂性(下面会说),最好还是较为完整的限制一下输入的字符种类。 
第二个看起来是没有什么问题的,但潜在的会带来一些隐患。这很容易给人造成的一个错觉是,我对输入的字符串已经很有效的做过处理了,以后使用没有什么问题。这句话没有错,对字符串来说这样做也是很正确的,但是他扮演了一个不光彩的角色,试想一下,如果过滤后的字符串放进了数据库,而后续的语句有直接拿出来使用的,这种对前面过滤的依赖性,是不是正确的呢? 
也许较好的做法应该是,针对具体的情况来确定过滤的准则。 
常见的输入变量有三种:数字,字符串还有集合。对于数字型的输入变量,简单调用一下判断函数即可,见得到的代码中,凡是检查了这类变量的,几乎都正确。对于字符串型的来说,基本上在插入到生成的SQL语句时,前后都有单引号,如果仅从破坏注入条件来看,把单引号替换成两个单引号应该问题不大。同理的,如果是一个字符串的集合,也可以简单的用这种方法。而如果是数字的集合,情况可能稍微麻烦一点,至少你得允许数字、逗号或许还有空格之类的符号在输入中正常出现,这样子的过滤规则可能显得复杂,不过你可以借鉴一下dvBBS6.1打过补丁后的版本,总的来说,对于已经发现的过滤漏洞而言,他们还是补得比较好的。 

本新闻共7页,当前在第3页  1  2  3  4  5  6  7  


上一篇:JHACKJ原创win2003硬盘权限设置
下一篇:Linux十大高级安全管理技巧
相关文章
Copyright 2005 - 2006 版权所有 北亚数据恢复中心
全国统一客服电话:4006-505-808 或 800-810-5880
地址:北京市海淀区学院南路68号吉安大厦C座(汇智楼)528
申明:本网站所有关于硬盘数据恢复硬盘维修的资料及工具全部来自网络,如有侵权,请通知我们,我们马上做出处理-北亚数据恢复中心。