论坛公告:应用容器安全指南(SP800-190)中文版   美国政府宣布禁用卡巴斯基软件   《中华人民共和国网络安全法》讨论帖   新手报到专用帖   【论坛公告】关于本站广告贴泛滥问题的整理通知   

当前时区为 UTC + 8 小时


发表新帖 回复这个主题  [ 46 篇帖子 ]  前往页数 上一页  1, 2, 3, 4  下一页
作者 内容
 文章标题 :
帖子发表于 : 2008-12-17 21:48 
离线
版主

注册: 2008-05-20 10:40
最近: 2015-07-20 17:49
拥有: 77.50 安全币

奖励: 198 安全币
在线: 2135 点
帖子: 117
等级保护第一级应用安全就提到:"应提供数据有效性检验功能,保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求。"

引用下而已,事实是要不相信任何来自外部的输入.做好对输入的过滤就可以解决SQL注入,和跨站的问题.

担心输入过滤不完全,就对输出也过滤,但这只是增加渗透工作的复杂程度.(如需要盲注什么的)


--------本帖迄今已累计获得32安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2009-07-16 17:11 
离线
顶级用户

关注按钮

注册: 2005-06-29 22:32
最近: 2017-06-11 20:54
拥有: 9,384.60 安全币

奖励: 1067 安全币
在线: 5485 点
帖子: 1296
地址: www.youxia.org
相对而言,最大的一些问题

跨站、注入、应用程序或者系统的漏洞

用IPS或者WAF能解决多数

比如注入和跨站,虽然有问题

但是ips和waf都能检测到

一些网页木马的操作也能检测并阻断

还算好…… 呵呵


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2009-07-17 11:21 
离线
中级用户

注册: 2008-02-18 16:32
最近: 2016-06-30 10:08
拥有: 1,683.40 安全币

奖励: 37 安全币
在线: 676 点
帖子: 65
网路游侠 写道:
相对而言,最大的一些问题

跨站、注入、应用程序或者系统的漏洞

用IPS或者WAF能解决多数

比如注入和跨站,虽然有问题

但是ips和waf都能检测到

一些网页木马的操作也能检测并阻断

还算好…… 呵呵


我没有用过WAF,这玩意儿到底有多大用处啊,我是有几点疑问:
对于一个HTTP请求,WAF是对包头进行侦测,还是对整个包进行侦测?
因为很多恶意代码不是在URL的参数中,而是在POST请求的参数里面。而对于flex结构的Web应用程序,请求的body内容有的时候是AMF格式的,现有的WAF能够解析吗。
对于使用HTTPS协议的Web应用,WAF如何解析请求包。
对于1' or '1'='1这种SQL注入的脚本,WAF如何进行模式匹配,过滤or,还是过滤单引号,如果这样的话,误报率会不会很大。
WAF本身有没有做好安全工作,因为国外某些过滤URL的产品中曾经爆出缓冲区溢出的漏洞,造成了用这个产品的网站反而成了容易被攻击的对象。最近的实例,也可以参考綠霸,使用了精心构造的URL可以造成缓冲区溢出。
大家有没有WAF的介绍文档,参考一下,最好是原理性的。


--------本帖迄今已累计获得30安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2009-09-11 23:50 
离线
版主

注册: 2005-03-05 09:28
最近: 2015-07-18 20:44
拥有: 4,166.30 安全币

奖励: 620 安全币
在线: 4182 点
帖子: 310
yangbo9297 写道:
做好最基本的防御工作
SQL的注入都需要通过不断的尝试才能成功,依赖于类似服务端报错的敏感提示等,所以首先我们应将服务器的错误信息全部屏蔽,只允许状态码为200 302之类的响应给客户,对于400 及500以上,特别是500以上的响应状太码绝对不输出给用户,这样就会安全许多


这是你的误区,sql注入并不需要依赖于错误信息的敏感提示,在没有出错信息下可以使用盲注、时间延迟法或者利用openxxxx等函数直接远程"copy"数据,如果注入点权限较高就直接执行系统命令也无需web敏感信息提示。


--------本帖迄今已累计获得51安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2009-09-23 12:34 
离线
版主

注册: 2008-05-20 10:40
最近: 2015-07-20 17:49
拥有: 77.50 安全币

奖励: 198 安全币
在线: 2135 点
帖子: 117
2个故事,请勿对号入座:

某大甲方负责安全的领导问:“你们发现我系统里有SQL注入漏洞,工具上能看到我们的表和字段,密码在哪呢?”

乙方技术:“这个没有。”

甲方负责安全的领导:“那数据库的内容怎么能看到的呢?把密码弄出来!这样看上去直观”。

乙方技术:“这个真没有。”

=========================
某次喝酒,席间某外资安全公司中层谈到SQL注入,说:

“你们注入,能看数据库表里的内容,那密码呢?”

某技术:“注入得不到。”

安全公司中层:“没密码,怎么能看到内容呢?”

很多技术人员:……—%%……#·()—)

10分钟后,解释不清,大家只好举杯喝酒。

30分钟后,喝了好多酒。

=========================

很多话题,讲了很多年,讲了很多遍,结果还是需要经常的科普。

不过,自古以来,人们就在预防被热水烫,防了几千年,想出了很多方法,如:给杯子加个把手,结果到了今天还有人被烫。

我相信很多人都参加过安全意识或者攻防演示的培训,现在看来,很多人一定上课的时候没注意听,单记住几个小故事了。


--------本帖迄今已累计获得47安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2009-12-30 13:00 
离线
初级用户

注册: 2009-12-15 20:03
最近: 2013-05-27 18:42
拥有: 96.00 安全币

奖励: 8 安全币
在线: 65 点
帖子: 31
在市面上,还有很多产品都是“特征库的匹配规则”来实现临时的、部分的安全。大部分的杀毒软件不就是靠特征库?但是这种方法还能持续多久?用户是否也喜欢这种方式呢?

我觉得安全产品不能再靠这种“特征库的匹配规则”的方式了。永远有延迟。终端用户需要下载特征库。1、终端用户不是再新问题出现马上得到特征库。2、特征库出来了,终端用户不是马上拿到。3、拿到了不一定马上应用。这种现象最常见的体现就是操作系统补丁。

现在的老一代的杀毒软件;
现在Web应用安全扫描软件,AppScan等;
现在所有的应用防火墙;
等等其他产品都是用了特征库,这种些产品靠特征库生存的几率能有多长?

我们能否学习下榜样:
新一带防病毒产品:360安全卫士,微点;
新一代的Web应用安全扫描器:NOSEC JSky。

不要再靠那些陈旧的永远落后的特征库来提供安全服务了。


--------本帖迄今已累计获得5安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-01-01 20:46 
离线
初级用户

注册: 2009-12-15 20:03
最近: 2013-05-27 18:42
拥有: 96.00 安全币

奖励: 8 安全币
在线: 65 点
帖子: 31
哈哈,拿免费的iiscan扫扫吧,问题解决咯,sql注入,XSS全部都挖出来


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-01-08 21:17 
离线
初级用户

注册: 2010-01-02 16:17
最近: 2014-12-10 21:33
拥有: 5,007.00 安全币

奖励: 0 安全币
在线: 5748 点
帖子: 44
thank you!!!!!!!


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-02-02 16:08 
离线
初级用户

注册: 2009-10-10 10:33
最近: 2015-05-31 22:45
拥有: 568.00 安全币

奖励: 141 安全币
在线: 4136 点
帖子: 55
我觉得sql injection的根本问题是因为过滤不严导致的,上边所说的使用设备过滤只是从数据包上进行过滤这起到的作用当然也很大,这就好像IDC公司对所谓的违法关键字进行过滤一样,肯定存在误报,解决sql注入的最终办法是安全编写代码,然后对代码进行安全审计,这样可以从根源上防止SQL注入。sql注入就是因为过滤不严格导致入侵者可以使用sql语句非法查询数据库。。。
//当然隐藏应用程序的banner等办法也可以防止一定的入侵事故发生,但是不能一概而论。


--------本帖迄今已累计获得53安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : 从根源做起才是最安全的
帖子发表于 : 2010-02-09 17:14 
离线
初级用户

注册: 2009-12-15 20:03
最近: 2013-05-27 18:42
拥有: 96.00 安全币

奖励: 8 安全币
在线: 65 点
帖子: 31
我想从根源做起是最安全的。
比如:
我的银行帐户里面就100元,黑客门都知道我的帐户号码,但是他难花心思来搞这么点钱;
如果我的帐户里有100万元,就算我用了指纹、密码器、口令牌,等等十层封锁,都无法阻止黑客门想去搞这笔钱。

如果黑客们发现你的代码编写没有任何问题,那他会直接走的。不用你加几十万的应用防火墙,再加网页防篡改软件等等。

人没病就不用吃药,我的意见,请大家指导。


--------本帖迄今已累计获得19安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-02-11 01:38 
离线
高级用户

注册: 2010-02-10 23:52
最近: 2013-03-10 00:00
拥有: 2,980.00 安全币

奖励: 745 安全币
在线: 4069 点
帖子: 263
我也来谈谈我自己的看法,一家之言:

也许是我学识有限,我真的不认为这些所谓的SQL注入和XSS跨站脚本攻击有这么洪水猛兽。SQL注入攻击归根到底是还是对用户输入不过滤或过滤不严格以及程序员的SQL语句编写能力不过关、安全意识差导致的,我认为要根除SQL过滤需要做到以下几点:

1、严格过滤客户端输入内容:不单单是使用JS而且服务器也要加上验证逻辑。其实JS过滤只局限于浏览器,瞒过它是很轻而易举的事情(大不了手工造包嘛),之所以用JS进行过滤是为了增加用户体验,恰恰有的程序员可能会因此而疏忽了,认为只要在客户端进行验证就够了,事实上在客户端做的验证只是徒劳而已。
2、对数据库进行严格授权,MSSQL的授权粒度已经到了某表某列的增删改操作,其它数据库我不是很清楚,但应该都差不多。比如果有个登录验证框,这个步骤只需用到查询权限就够了,而如果我们给了更多权限甚至是DB owner,那么无疑将造成很大的隐患。
3、不使用拼接的SQL语句而采用存储过程或带参数的查询语句(这两种方式会对参数值进行编码,从根本上掐死注入途径)。



而对于XSS脚本攻击:

1、类似于对SQL注入的防范,应该严格过滤用户输入,一个对数字字段的查询我们没必要允许用户输入非数字关键字进行查询。
2、严格控制输出,对输出中的html进行encoding,对于"<script scr=""></script>"等我们直接让浏览器原原本本输出就行了,而不是让浏览器傻傻地加载这个脚本文件。
3、使用HttpOnly Cookies,窃取Cookies是XSS攻击的主要目的,而HttpOnly技术可以限制浏览器脚本读取Cookies。现在几乎所有高版本浏览器都已经支持了HttpOnly特性,当然次技术还要被程序员采用才行。


在我看来,这些问题都可以完全避免的,这些技术地球人都在用,可为什么有的人一用就有问题呢?技术本身没问题,人的因素最重要,所以我觉得什么防火墙什么IDS/IPS这些东西都是治标不治本而已,是很可笑的!

本人初来宝地,才疏学浅,如有异议还望指正,谢谢:)


--------本帖迄今已累计获得37安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : Re: 从根源做起才是最安全的
帖子发表于 : 2010-02-11 14:12 
离线
版主

关注按钮

注册: 2010-01-17 15:42
最近: 2013-05-17 18:04
拥有: 1,091.00 安全币

奖励: 157 安全币
在线: 964 点
帖子: 107
beatyouman 写道:
人没病就不用吃药
有一种药物的作用叫做“预防作用”。一个黑客看了你的代码,然后你就因为你写的代码天下无敌了,然后放心悠哉悠哉,忽然有一天,一位搞入门的小黑客路过你的代码时,却发现你的代码的一个“大窟窿”.....

没有绝对的安全,你的水平或者一个黑客的水平不代表所有人的水平,有句名言叫“黑客外面有黑客”

http://hi.baidu.com/hi_heige/blog/item/ ... f9dfa.html


--------本帖迄今已累计获得37安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-02-11 14:35 
离线
版主

关注按钮

注册: 2010-01-17 15:42
最近: 2013-05-17 18:04
拥有: 1,091.00 安全币

奖励: 157 安全币
在线: 964 点
帖子: 107
LaurelW 写道:
在我看来,这些问题都可以完全避免的


有的东西说起来容易做起来难!还是那句老话没有绝对的安全。这个是千古都不会改变的。

引用:
SQL注入攻击归根到底是还是对用户输入不过滤或过滤不严格以及程序员的SQL语句编写能力不过关、安全意识差导致的


首先过滤=\=安全,绕过某些过滤的例子很多,至于过滤不严,这个问题很难说清楚,比如有的过滤有的人认为是安全的没有破绽,而有的人看了后直接可以秒杀【在楼是的回复也说明了这个问题】,然后你说程序员的水平问题及安全意识问题,水平在高的程序员 也会出问题,就是专业的安全人员写出的代码一样有可能有问题.....


引用:
1、严格过滤客户端输入内容:不单单是使用JS而且服务器也要加上验证逻辑。其实JS过滤只局限于浏览器,瞒过它是很轻而易举的事情(大不了手工造包嘛),之所以用JS进行过滤是为了增加用户体验,恰恰有的程序员可能会因此而疏忽了,认为只要在客户端进行验证就够了,事实上在客户端做的验证只是徒劳而已。
2、对数据库进行严格授权,MSSQL的授权粒度已经到了某表某列的增删改操作,其它数据库我不是很清楚,但应该都差不多。比如果有个登录验证框,这个步骤只需用到查询权限就够了,而如果我们给了更多权限甚至是DB owner,那么无疑将造成很大的隐患。
3、不使用拼接的SQL语句而采用存储过程或带参数的查询语句(这两种方式会对参数值进行编码,从根本上掐死注入途径)。


1.过滤这个问题上面谈过了
2.数据库"严格授权",这个基本上只可以提高利用的一些门槛,一个注射点可以做的事情很多,public又怎么样,一样有秒杀的情况
3.使用参数查询这个是一个比较好的习惯,但是在具体的代码编写中,很多情况很难预料的:http://hi.baidu.com/hi_heige/blog/item/0ceb3cdc8049d1de8d1029b6.html

引用:
1、类似于对SQL注入的防范,应该严格过滤用户输入,一个对数字字段的查询我们没必要允许用户输入非数字关键字进行查询。
2、严格控制输出,对输出中的html进行encoding,对于"<script scr=""></script>"等我们直接让浏览器原原本本输出就行了,而不是让浏览器傻傻地加载这个脚本文件。
3、使用HttpOnly Cookies,窃取Cookies是XSS攻击的主要目的,而HttpOnly技术可以限制浏览器脚本读取Cookies。现在几乎所有高版本浏览器都已经支持了HttpOnly特性,当然次技术还要被程序员采用才行。


1、2还是过滤问题,随便举个列子yahoo hotmail ...等多少安全牛人设计维护的,还不是持续的被暴xss?
3.httponly类似你sql注射里说的那个授权问题一样,只是提高了利用的门槛,只要执行js那利用的空间太大了:http://hi.baidu.com/hi_heige/blog/item/5772bdc2b98a9b5fb219a868.html


--------本帖迄今已累计获得31安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-02-11 17:55 
离线
高级用户

注册: 2010-02-10 23:52
最近: 2013-03-10 00:00
拥有: 2,980.00 安全币

奖励: 745 安全币
在线: 4069 点
帖子: 263
引用:
superhei 写道:
LaurelW 写道:
在我看来,这些问题都可以完全避免的


有的东西说起来容易做起来难!还是那句老话没有绝对的安全。这个是千古都不会改变的。

引用:
SQL注入攻击归根到底是还是对用户输入不过滤或过滤不严格以及程序员的SQL语句编写能力不过关、安全意识差导致的


首先过滤=\=安全,绕过某些过滤的例子很多,至于过滤不严,这个问题很难说清楚,比如有的过滤有的人认为是安全的没有破绽,而有的人看了后直接可以秒杀【在楼是的回复也说明了这个问题】,然后你说程序员的水平问题及安全意识问题,水平在高的程序员 也会出问题,就是专业的安全人员写出的代码一样有可能有问题.....




“过滤!=安全,绕过某些过滤的例子很多”,这个就不好讨论了,因为我们也不知道当时是怎么绕过去的,也不知道而当时的服务器代码是如何做过滤的,你说提到的“秒杀”字眼太过于轻巧了。
说到底还是人的问题吧,就算是老虎也有打盹的时候。我也不是说编写出有漏洞程序的那些人统统都是笨蛋。一个人写出来的程序放到网上,却要去面对成千上万的潜在入侵者的渗透尝试,难免会有顾不及的地方出现。


引用:

引用:
1、严格过滤客户端输入内容:不单单是使用JS而且服务器也要加上验证逻辑。其实JS过滤只局限于浏览器,瞒过它是很轻而易举的事情(大不了手工造包嘛),之所以用JS进行过滤是为了增加用户体验,恰恰有的程序员可能会因此而疏忽了,认为只要在客户端进行验证就够了,事实上在客户端做的验证只是徒劳而已。
2、对数据库进行严格授权,MSSQL的授权粒度已经到了某表某列的增删改操作,其它数据库我不是很清楚,但应该都差不多。比如果有个登录验证框,这个步骤只需用到查询权限就够了,而如果我们给了更多权限甚至是DB owner,那么无疑将造成很大的隐患。
3、不使用拼接的SQL语句而采用存储过程或带参数的查询语句(这两种方式会对参数值进行编码,从根本上掐死注入途径)。



1.过滤这个问题上面谈过了
2.数据库"严格授权",这个基本上只可以提高利用的一些门槛,一个注射点可以做的事情很多,public又怎么样,一样有秒杀的情况
3.使用参数查询这个是一个比较好的习惯,但是在具体的代码编写中,很多情况很难预料的:http://hi.baidu.com/hi_heige/blog/item/0ceb3cdc8049d1de8d1029b6.html




"一个注射点可以做的事情很多",如果恰巧数据库管理员授予了这个web程序db owner的权限,而这个web恰巧又被发现有注入漏洞了,那么这个注入点的确可以做很多事情。但是假如我只给了查询权限(因为实际上只用到了查询功能),并且使用了参数过滤,使用了存储过程,如果这样还可以注入那么天下可以大乱了。的确很多事情是很难预料的,但这并不足以反驳我的观点:)

引用:
引用:
1、
类似于对SQL注入的防范,应该严格过滤用户输入,一个对数字字段的查询我们没必要允许用户输入非数字关键字进行查询。
2、严格控制输出,对输出中的html进行encoding,对于"<script scr=""></script>"等我们直接让浏览器原原本本输出就行了,而不是让浏览器傻傻地加载这个脚本文件。
3、使用HttpOnly Cookies,窃取Cookies是XSS攻击的主要目的,而HttpOnly技术可以限制浏览器脚本读取Cookies。现在几乎所有高版本浏览器都已经支持了HttpOnly特性,当然次技术还要被程序员采用才行。



1、2还是过滤问题,随便举个列子yahoo hotmail ...等多少安全牛人设计维护的,还不是持续的被暴xss?
3.httponly类似你sql注射里说的那个授权问题一样,只是提高了利用的门槛,只要执行js那利用的空间太大了:http://hi.baidu.com/hi_heige/blog/item/5772bdc2b98a9b5fb219a868.html




的确,不利用cookie也可以,也没人规定说XSS就一定要偷Cookie才行,而HttpOnly也只是防范Cookie被偷而已。但不利用无疑会给渗透带来几何级难度的增长。
以上的防范犯法我只是把我想到的说出来而已,也并不是说只要做到我以上的那些就可以万事大吉了。

防范跨脚本攻击还需要做得更更多:
1、严格限制get/post/put/delete以及XMLHttp的操作,如果做到这一点,那么想直接在后台执行ajax代码的指望也基本落空了:)
2、Cookie的domain范围尽量不要放太大

最后,感谢这位同志的反驳观点,但遗憾的是都没有命中要害:)


--------本帖迄今已累计获得5安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 :
帖子发表于 : 2010-02-11 18:47 
离线
版主

关注按钮

注册: 2010-01-17 15:42
最近: 2013-05-17 18:04
拥有: 1,091.00 安全币

奖励: 157 安全币
在线: 964 点
帖子: 107
哎,不想和你做无谓的口舌之争,我想你也没有认真看我的说的东西 就急急忙忙回贴了

而且还有玩文字游戏的嫌疑。

主要的问题是你的论定是建立在你自己的知识水平上的,你不知道的事情或者技术还很多,不要以你自己的水平来衡量别人的水平【当然我不知道你的水平 我也有这个嫌疑?】

你自己想想把为什么大公司每年都投资那么人力财力在安全上面,但是还是那么屡报漏洞呢?

我说的那些都是有技术根据的,我想这个论坛里还是有人知道一些的....


--------本帖迄今已累计获得14安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 46 篇帖子 ]  前往页数 上一页  1, 2, 3, 4  下一页

当前时区为 UTC + 8 小时


在线用户

正在浏览此版面的用户:没有注册用户 和 1 位游客


不能 在这个版面发表主题
不能 在这个版面回复主题
不能 在这个版面编辑帖子
不能 在这个版面删除帖子
不能 在这个版面提交附件

前往 :  
cron
华安信达(CISPS.org) ©2003 - 2012