62,046
社区成员
发帖
与我相关
我的任务
分享问个服务器安全的问题
服务器上有.net的几个站和asp的几个站
那几个asp的站经常被黑,就是目录下文件多了index.htm,index.html,index.php,defalut.htm,default.html....
等近十个文件,严重时每个文件夹下都有,访问网站就出现 hacked by ....的黑色屏幕,还得一个一个删!很烦人的!
像这样的情况该如何处理,如何防范?
.net站确没有,我想知道,这是哪里的安全问题?请指点
那几个asp的站经常被黑,就是目录下文件多了index.htm,index.html,index.php,defalut.htm,default.html....
等近十个文件,严重时每个文件夹下都有,访问网站就出现 hacked by ....的黑色屏幕,还得一个一个删!很烦人的!
像这样的情况该如何处理,如何防范?
.net站确没有,我想知道,这是哪里的安全问题?请指点
...全文
请发表友善的回复…
发表回复
lorinzhang 2010-07-19
- 打赏
- 举报
[Quote=引用 3 楼 jiuchunyoung 的回复:]
ASP.NET常见安全问题
一、SQL语句漏洞
许多程序员在用sql语句进行用户密码验证时是通过一个类似这样的语句来实现的：
Sql="Select * from 用户表 where 姓名 = '" + name + "' and 密码 = '" + password + "'"
通过分析可以发现，上述语句存在着致命的漏洞。当我们在用户名称中输入下面的字符串时：test' ……
[/Quote]
多谢,我仔细读读...
ASP.NET常见安全问题
一、SQL语句漏洞
许多程序员在用sql语句进行用户密码验证时是通过一个类似这样的语句来实现的：
Sql="Select * from 用户表 where 姓名 = '" + name + "' and 密码 = '" + password + "'"
通过分析可以发现，上述语句存在着致命的漏洞。当我们在用户名称中输入下面的字符串时：test' ……
[/Quote]
多谢,我仔细读读...
萤火架构 2010-07-19
- 打赏
- 举报
asp的程序存在漏洞，需要检查程序，
可以把asp的FSO权限封掉，但是可能影响你的程序运行
可以把asp的FSO权限封掉，但是可能影响你的程序运行
lorinzhang 2010-07-19
- 打赏
- 举报
[Quote=引用 1 楼 gxingmin 的回复:]
把这些网站目录aps.net用户写权限去掉，即只能读，不能写
[/Quote]
那需要存放上传图片的目录怎么配,不没法传了吗?
把这些网站目录aps.net用户写权限去掉，即只能读，不能写
[/Quote]
那需要存放上传图片的目录怎么配,不没法传了吗?
george010 2010-07-19
- 打赏
- 举报
黑客也太无聊了吧，还留名？
JiuchunYoung 2010-07-19
- 打赏
- 举报
ASP.NET常见安全问题
一、SQL语句漏洞
许多程序员在用sql语句进行用户密码验证时是通过一个类似这样的语句来实现的：
Sql="Select * from 用户表 where 姓名 = '" + name + "' and 密码 = '" + password + "'"
通过分析可以发现，上述语句存在着致命的漏洞。当我们在用户名称中输入下面的字符串时：test' or '1' = '1，然后口令随便输入，我们设为aaa。变量代换后，sql语句就变成了下面的字符串：
Sql="Select * from 用户表 where 姓名='test' or '1' = '1' and 密码 = 'aaa'
我们都知道select语句在判断查询条件时，遇到或（or）操作就会忽略下面的与（and）操作，而在上面的语句中1=1的值永远为true，这意味着无论在密码中输入什么值，均能通过上述的密码验证！
Select * from 用户表 where 姓名 = '合法的姓名' or '1' = '1' and 密码 = '' //无需密码
Select * from 用户表 where 姓名 = '' or '1'='1' and 密码 = '' or '1'='1' //无需用户名和密码
Select * from 用户表 where 姓名 = '合法的姓名' --' and 密码 = '' //无需密码
解决方法：
防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行：
1、检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。
2、对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号。
第二：删除用户输入内容中的所有连字符。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
3、用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。用参数化查询，这样语句就变为Sql="Select * from 用户表 where 姓名 = @Name and 密码 = @Pass,这样就杜绝'字符所造成的漏洞了。
4、限制输入的长度。
5、将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
6、检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
二、HTML语法漏洞
如果没有对用户发言作出HTML语句过滤，就会让恶意破坏的用户利用html写出js攻击语句，典型的如不断开窗口直至死机，win9x死机等！
解决方法：
将HTML语句加密一下就行了，如：Server.HtmlEncode("用户发言")，也可直接过滤'<>这些HTML语法符号，如果想使用HTML语法的用户不妨用UBB语法代替！
一、SQL语句漏洞
许多程序员在用sql语句进行用户密码验证时是通过一个类似这样的语句来实现的：
Sql="Select * from 用户表 where 姓名 = '" + name + "' and 密码 = '" + password + "'"
通过分析可以发现，上述语句存在着致命的漏洞。当我们在用户名称中输入下面的字符串时：test' or '1' = '1，然后口令随便输入，我们设为aaa。变量代换后，sql语句就变成了下面的字符串：
Sql="Select * from 用户表 where 姓名='test' or '1' = '1' and 密码 = 'aaa'
我们都知道select语句在判断查询条件时，遇到或（or）操作就会忽略下面的与（and）操作，而在上面的语句中1=1的值永远为true，这意味着无论在密码中输入什么值，均能通过上述的密码验证！
Select * from 用户表 where 姓名 = '合法的姓名' or '1' = '1' and 密码 = '' //无需密码
Select * from 用户表 where 姓名 = '' or '1'='1' and 密码 = '' or '1'='1' //无需用户名和密码
Select * from 用户表 where 姓名 = '合法的姓名' --' and 密码 = '' //无需密码
解决方法：
防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行：
1、检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。
2、对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号。
第二：删除用户输入内容中的所有连字符。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
3、用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。用参数化查询，这样语句就变为Sql="Select * from 用户表 where 姓名 = @Name and 密码 = @Pass,这样就杜绝'字符所造成的漏洞了。
4、限制输入的长度。
5、将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
6、检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
二、HTML语法漏洞
如果没有对用户发言作出HTML语句过滤，就会让恶意破坏的用户利用html写出js攻击语句，典型的如不断开窗口直至死机，win9x死机等！
解决方法：
将HTML语句加密一下就行了，如：Server.HtmlEncode("用户发言")，也可直接过滤'<>这些HTML语法符号，如果想使用HTML语法的用户不妨用UBB语法代替！
JiuchunYoung 2010-07-19
- 打赏
- 举报
千万不要轻视正确配置安全设置的重要性。如果不正确配置安全设置，不但会使您的 ASP 应用程序遭受不必要的篡改，而且会妨碍正当用户访问您的 .asp 文件。 Web 服务器提供了各种方法来保护您的 ASP 应用程序免受未授权的访问和篡改。在您读完本主题下的安全信息之后，请花一定的时间仔细检查一下您的 Windows NT 和 Web 服务器安全性文档。 NTFS 权限 您可以通过为单独的文件和目录应用 NTFS 访问权限来保护 ASP 应用程序文件。NTFS 权限是 Web 服务器安全性的基础，它定义了一个或一组用户访问文件和目录的不同级别。当拥有 Windows NT 有效帐号的用户试图访问一个有权限限制的文件时，计算机将检查文件的访问控制表 (ACL)。该表定义了不同用户和用户组所被赋予的权限。如果用户的帐号具有打开文件的权限，计算机则允许该用户访问文件。例如，Web 服务器上的 Web 应用程序的所有者需要有“更改”权限来查看、更改和删除应用程序的 .asp 文件。但是，访问该应用程序的公共用户应仅被授予“只读”权限，以便将其限制为只能查看而不能更改应用程序的 Web 页。 维护 Global.asa 的安全 为了充分保护 ASP 应用程序，一定要在应用程序的 Global.asa 文件上为适当的用户或用户组设置 NTFS 文件权限。如果 Global.asa 包含向浏览器返回信息的命令而您没有保护 Global.asa 文件，则信息将被返回给浏览器，即便应用程序的其他文件被保护。 注意 一定要对应用程序的文件应用统一的 NTFS 权限。例如，如果您不小心过度限制了一应用程序需要包含的文件的 NTFS 权限，则用户可能无法查看或运行该应用程序。为了防止此类问题，在为您的应用程序分配 NTFS 权限之前应仔细计划。 Web 服务器权限 您可以通过配置您的 Web 服务器的权限来限制所有用户查看、运行和操作您的 ASP 页的方式。不同于 NTFS 权限提供的控制特定用户对应用程序文件和目录的访问方式， Web 服务器权限应用于所有用户，并且不区分用户帐号的类型。 对于要运行您的 ASP 应用程序的用户，在设置 Web 服务器权限时，必须遵循下列原则： 对包含 .asp 文件的虚拟目录允许“读”或“脚本”权限。 对 .asp 文件和其他包含脚本的文件（如 .htm 文件等）所在的虚目录允许“读”和“脚本”权限。 对包含 .asp 文件和其他需要“执行”权限才能运行的文件（如 .exe 和 .dll 文件等）的虚目录允许“读”和“执行”权限。 脚本映射文件 应用程序的脚本映射保证了 Web 服务器不会意外地下载 .asp 文件的源代码。例如，即使您为包含了某个 .asp 文件的目录设置了“读”权限，只要该 .asp 文件隶属于某个脚本映射应用程序，那么您的 Web 服务器就不会将该文件的源代码返回给用户。 Cookie 安全性 ASP 使用 SessionID cookie 跟踪应用程序访问或会话期间特定的 Web 浏览器的信息。这就是说，带有相应的 cookie 的 HTTP 请求被认为是来自同一 Web 浏览器。Web 服务器可以使用 SessionID cookies 配置带有用户特定会话信息的 ASP 应用程序。例如，如果您的应用程序是一个允许用户选择和购买 CD 唱盘的联机音乐商店，就可以用 SessionID 跟踪用户漫游整个应用程序时的选择。 SessionID 能否被黑客猜中？ 为了防止计算机黑客猜中 SessionID cookie 并获得对合法用户的会话变量的访问，Web 服务器为每个 SessionID 指派一个随机生成号码。每当用户的 Web 浏览器返回一个 SessionID cookie 时，服务器取出 SessionID 和被赋予的数字，接着检查是否与存储在服务器上的生成号码一致。若两个号码一致，将允许用户访问会话变量。这一技术的有效性在于被赋予的数字的长度（64 位），此长度使计算机黑客猜中 SessionID 从而窃取用户的活动会话的可能性几乎为 0。 加密重要的 SessionID Cookie 截获了用户 sessionID cookie 的计算机黑客可以使用此 cookie 假冒该用户。如果 ASP 应用程序包含私人信息，信用卡或银行帐户号码，拥有窃取的 cookie 的计算机黑客就可以在应用程序中开始一个活动会话并获取这些信息。您可以通过对您的 Web 服务器和用户的浏览器间的通讯链路加密来防止 SessionID cookie 被截获。 使用身份验证机制保护被限制的 ASP 内容 您可以要求每个试图访问被限制的 ASP 内容的用户必须要有有效的 Windows NT 帐号的用户名和密码。每当用户试图访问被限制的内容时，Web 服务器将进行身份验证，即确认用户身份，以检查用户是否拥有有效的 Windows NT 帐号。
gxingmin 2010-07-19
- 打赏
- 举报
把这些网站目录aps.net用户写权限去掉，即只能读，不能写
