论文部分内容阅读
摘 要：本文结合ASP动态网站开发经验，对ASP程序设计存在的信息安全隐患进行分析，讨论了ASP程序常见的安全漏洞，从程序设计角度对WEB信息安全及防范提供了参考。
关键词：ASP 程序设计 WEB 信息安全
中图分类号：TP311.1文献标识码：A
文章编号：1673-8454（2007）11-0070-02
WWW应用服务，是目前因特网应用最为广泛的服务，随着网络对人们生活方式的不断影响和改变，人们越来越依赖于这种服务。然而WEB信息安全现状却不容乐观。WEB信息安全威胁可来自计算机病毒、操作系统、以及数据库系统等潜在的安全漏洞，还可来自于WEB程序代码编写的不完善。本文从ASP程序设计角度对WEB信息安全及防范进行分析讨论。
一、ASP程序设计与脚本信息泄漏隐患
（1） .bak文件
有些程序员习惯将程序代码的备份文件存储为.bak文件，而.bak文件的内容可以通过浏览器进行查看，这就埋下了源代码泄漏的隐患，将可能导致敏感信息如数据库名、表名、用户名、密码、文件目录等信息的泄漏。
（2） .inc文件
有些程序员喜欢把常用的代码或配置信息写在一个.inc文件中，如conn.inc、global.inc、shared.inc等等。.inc、 .bak文件和其它文本一样，当在浏览器中浏览时，会毫无保留地显示其内容。攻击者可借助搜索引擎快速地查找到存在脚本泄漏隐患的网站及其中包含敏感数据信息的文件。如果利用搜索引擎搜索“conn.inc”，则会暴露出许多网站存在脚本信息泄露隐患。因此重要信息，如数据库连接或配置信息不能以inc为后缀命名，应以 .asp 命名；也可将数据库连接保存在Application中，直接引用，但这种方式对系统资源有消耗。
二、ASP程序设计与验证不全漏洞
程序设计时，通常在浏览敏感信息之前需进行用户验证，验证通过后，用户就获得了敏感信息的访问权。但是如果用户跨过验证入口后，对于敏感区域内部的其它网页就不再进行验证，那么这个验证就形同虚设，不法用户会利用这个漏洞，绕过验证页，直接通过链接地址浏览网页，造成敏感信息泄露。因此，在程序设计时必须确认每一个访问请求是经合法用户发出，敏感区的每一个网页都需验证后才能浏览。可以使用session变量解决验证不全漏洞。
例如：将用户名、密码定义为session变量：
如果经验证该用户是合法用户，就定义Session变量：
session("UserName ")=UserName
session("PassWord")=PassWord
敏感区的每一个文件都需验证上述这两个session变量，如果session("UserName ")和session("PassWord")不为空，则是合法用户；反之，则应跳转到登录页面进行登录验证，这样就给敏感区的每一个页面加上了安全保护。
三、ASP程序设计与SQL 注入漏洞
在B/S应用开发模式下，程序代码如果对用户输入数据的合法性不进行检测或检测不严，就会使应用程序存在安全隐患。攻击者可以通过浏览器的输入区域，利用某些特殊构造的SQL语句插入SQL的特殊字符和指令，从而收集程序及服务器的信息，获取想得到的资料，甚至获取网站管理员的帐号和密码，这就是SQL注入（SQL Injection）。SQL注入通过正常的WWW端口对页面请求访问，和正常的WEB页面访问没什么区别，因此，SQL注入能够避免大多数防火墙的防御，绕过系统的安全防护。因此防御SQL漏洞攻击依赖于完善的程序代码。
SQL注入的手法比较灵活，既可以在浏览器的地址栏进行，也可以通过表单输入框进行，如利用用户名、密码输入框；文本输入框、下拉菜单等进行SQL注入攻击。如果程序代码对用户输入信息检测不严格，就可能导致服务器执行恶意指令威胁信息安全。
在B/S系统编程过程中，经常需依据用户的输入信息执行查询操作，下面是一个利用用户名、密码输入框进行注入攻击的例子。如：
sql="select * from 表名 where username=′"
关键词：ASP 程序设计 WEB 信息安全
中图分类号：TP311.1文献标识码：A
文章编号：1673-8454（2007）11-0070-02
WWW应用服务，是目前因特网应用最为广泛的服务，随着网络对人们生活方式的不断影响和改变，人们越来越依赖于这种服务。然而WEB信息安全现状却不容乐观。WEB信息安全威胁可来自计算机病毒、操作系统、以及数据库系统等潜在的安全漏洞，还可来自于WEB程序代码编写的不完善。本文从ASP程序设计角度对WEB信息安全及防范进行分析讨论。
一、ASP程序设计与脚本信息泄漏隐患
（1） .bak文件
有些程序员习惯将程序代码的备份文件存储为.bak文件，而.bak文件的内容可以通过浏览器进行查看，这就埋下了源代码泄漏的隐患，将可能导致敏感信息如数据库名、表名、用户名、密码、文件目录等信息的泄漏。
（2） .inc文件
有些程序员喜欢把常用的代码或配置信息写在一个.inc文件中，如conn.inc、global.inc、shared.inc等等。.inc、 .bak文件和其它文本一样，当在浏览器中浏览时，会毫无保留地显示其内容。攻击者可借助搜索引擎快速地查找到存在脚本泄漏隐患的网站及其中包含敏感数据信息的文件。如果利用搜索引擎搜索“conn.inc”，则会暴露出许多网站存在脚本信息泄露隐患。因此重要信息，如数据库连接或配置信息不能以inc为后缀命名，应以 .asp 命名；也可将数据库连接保存在Application中，直接引用，但这种方式对系统资源有消耗。
二、ASP程序设计与验证不全漏洞
程序设计时，通常在浏览敏感信息之前需进行用户验证，验证通过后，用户就获得了敏感信息的访问权。但是如果用户跨过验证入口后，对于敏感区域内部的其它网页就不再进行验证，那么这个验证就形同虚设，不法用户会利用这个漏洞，绕过验证页，直接通过链接地址浏览网页，造成敏感信息泄露。因此，在程序设计时必须确认每一个访问请求是经合法用户发出，敏感区的每一个网页都需验证后才能浏览。可以使用session变量解决验证不全漏洞。
例如：将用户名、密码定义为session变量：
如果经验证该用户是合法用户，就定义Session变量：
session("UserName ")=UserName
session("PassWord")=PassWord
敏感区的每一个文件都需验证上述这两个session变量，如果session("UserName ")和session("PassWord")不为空，则是合法用户；反之，则应跳转到登录页面进行登录验证，这样就给敏感区的每一个页面加上了安全保护。
三、ASP程序设计与SQL 注入漏洞
在B/S应用开发模式下，程序代码如果对用户输入数据的合法性不进行检测或检测不严，就会使应用程序存在安全隐患。攻击者可以通过浏览器的输入区域，利用某些特殊构造的SQL语句插入SQL的特殊字符和指令，从而收集程序及服务器的信息，获取想得到的资料，甚至获取网站管理员的帐号和密码，这就是SQL注入（SQL Injection）。SQL注入通过正常的WWW端口对页面请求访问，和正常的WEB页面访问没什么区别，因此，SQL注入能够避免大多数防火墙的防御，绕过系统的安全防护。因此防御SQL漏洞攻击依赖于完善的程序代码。
SQL注入的手法比较灵活，既可以在浏览器的地址栏进行，也可以通过表单输入框进行，如利用用户名、密码输入框；文本输入框、下拉菜单等进行SQL注入攻击。如果程序代码对用户输入信息检测不严格，就可能导致服务器执行恶意指令威胁信息安全。
在B/S系统编程过程中，经常需依据用户的输入信息执行查询操作，下面是一个利用用户名、密码输入框进行注入攻击的例子。如：
sql="select * from 表名 where username=′"