Anti SQL Inject

风格不统一 提交于 2020-02-03 02:39:04

1.Web 应用程序执行时如果发生异常,通过配置严禁将任何技术信息暴露:
 Web.Config:  

<customErrors mode="RemoteOnly" />

2.在客户端应用程序
 2.1 程序代码中一定要拼接 "参数化 SQL" ,并采取安全的"命令参数式" ADO.Net API
  ,连接数据库并提交该查询,另外今后尽量减少应用程序拼接 SQL,而多使用存储过程。
  参阅如下代码:

Code

 2.2 程序代码中直接调用存储过程,采取安全的"命令参数式" ADO.Net API,连接数据库并提交,
  不要以 CommandType.Text 的方式使用ADO.Net API 执行类似 exec sp_help 'sysobjects' 语句。
  参阅代码同前
3.数据库服务器端程序
 3.2 存储过程 T-SQL 程序代码中,如果其传入参数只用于静态 SQL ,且客户端采取安全的"命令参数式"
  ADO.Net API 调用该存储过程,则是安全代码,自动免疫 SQL 注入攻击。
  参阅如下代码:

Code




SQL 2000+ XQuery解决参数化In子句的问题

Code

SQL 2008 UDT 解决参数化 In 子句的问题

Code

 

Code


SQL 2000 + Split String to Table

Code

C# 参数化 SQL in 子句

Code

1. 采用最少权限的原则
运行脚本或执行代码的进程应当尽可能用权限最少的帐户运行,从而在危及进程安全时限制可能造成的破坏。如果恶意用户设法将代码注入某个服务器进程,那么授予该进程的权限会在很大程度上决定该用户可执行的操作类型。应当将需要更多信任(和更高权限)的代码分别隔离在不同的进程内。
2. 使用纵深防御
在应用程序中的每一层和每个子系统中设置检查点。检查点是网关守卫,它们确保只有经过身份验证和授权的用户能够访问下一个下游层。
3. 不要信任用户输入
应用程序彻底验证所有用户输入,然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地错误使用和某些人通过在系统中注入恶意命令蓄意进行攻击的情况,这种预防性措施对应用程序起到了保护作用。常见的攻击包括 SQL 注入攻击、脚本注入和缓冲区溢出。
4. 使用默认安全设置
杜绝仅仅为了使应用程序运行而使用安全性较低的设置。如果应用程序所需的功能不得不减小默认安全设置的安全级别或更改默认的安全设置,在更改前,充分测试更改所带来的后果,并了解可能带来的隐患。
5. 不要通过隐藏来保障安全
尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置,这些方法都不能提供绝对的安全保障。最好使用平台功能或使用已被证实可行的技术来保护数据。
6. 在关口进行检查
在关口检查客户端意思是在第一个身份验证点(例如,Web 服务器上的 Web 应用程序内)授予用户权限,并确定允许用户访问的资源和操作(可能由下游服务提供)。如果在关口设计可靠的身份验证和授权策略,就不必将原调用方的安全上下文一路委派到应用程序数据层。
7. 假定外部系统是不安全的系统
如果外部系统不归您所有,不要假定有人为您保证安全。
8. 减小表面区域
避免公开不需要公开的信息。如果公开这些信息,就可能进一步引起漏洞。同时,处理错误的方式一定要适当。向最终用户返回错误消息时,不要公开任何不需要公开的信息。
9. 以安全的方式显示错误消息
如果应用程序失败,一定要保护好机密数据。同时,不要在错误消息中提供过于详细的数据,也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。详细的错误信息应写入 Windows 事件日志。
10, 不要忘记您的安全程度受最薄弱环节制约
考虑安全性时,应该将应用程序所有层的安全性都考虑在内。
11. 禁用不使用的内容
通过禁用应用程序不需要的模块和组件来去除一些潜在的攻击点。例如,如果应用程序不使用输出缓存,则应禁用 ASP.NET 输出缓存模块。这样,即使以后在该模块中发现安全漏洞,应用程序也不会受到威胁。

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!