OWASP Top 10 Security Issue
10个安全隐患列表:
• Injection
– 注入
• Cross-Site Scripting (XSS)
– 跨站脚本
• Broken Authentication and Session Management
– 错误的认证和会话管理
• Insecure Direct Object References
– 不正确的直接对象引用
• Cross-Site Request Forgery (CSRF)
– 伪造跨站请求
• Security Misconfiguration
– 安全配置错误
• Insecure Cryptographic Storage
– 不安全的加密存储
• Failure to Restrict URL Access
– 不限制URL访问
• Insufficient Transport Layer Protection
– 传输层保护不足
• Unvalidated Redirects and Forwards
– 未验证的重定向和传递
解决办法概要
• Injection
– sql语句全部使用参数形式调用，不拼sql语句
– 对输入都要验证：客户端验证+服务器端验证
– 数据库操作的授权
– 针对每个输入Field，来验证字符串是否允许输入
• Cross-Site Scripting (XSS)
– 输入参数,使用微软的Anti-XSS组件过滤
– 输出到界面html元素’s string, 使用微软的Anti-XSS组件过滤
– SRE(Security Runtime Engine) HttpModule全自动方式
• Broken Authentication and Session Management
– 标示session的cookie设置为HttpOnly Cookie
– Session, cookie, cache设置过期时间
– 不使用cookieless模式
– 注销动作需要销毁所有和session相关的设置，比如cache, cookie等
• Insecure Direct Object References
– 业务对象表：技术主键ID（Int）+对外引用ID(Guid)
– application layer: 增加一些HashTable==> Guid-->Int 对应关系全局缓存
• Cross-Site Request Forgery (CSRF)
– 使用微软的Anti-CSRF组件过滤每个post请求
• Security Misconfiguration(NEW)
– Web.config命令行加密
• Insecure Cryptographic Storage
– 对称加密配合随机的PasswordSalt参数
– 加密算法尽量使用DES等，因为SH1、MD5加密已经被认为破解了
• Failure to Restrict URL Access
– 使用给每个aspx页面写basepage以达到对每个页面进行权限判断
• Insufficient Transport Layer Protection
– 验证页面：ssl， httponly, cookie
• UnvalidatedRedirects and Forwards (NEW)
– 针对每个需要重定向的url进行验证是否合法
应对之法
Injection
• 针对sql的操作都使用参数方式调用
• 不使用动态sql
• 如果使用linq/entity framework可降低这种安全隐患的几率
• 在入口限制允许输入的数据，比如年龄这个field，在页面中限制住只允许数字，不能超过100，不能小于0
• 除了表示层的验证外，业务逻辑层还要验证一次
Cross-Site Scripting (XSS)
• 过滤输入的参数
• 过滤输出的文本
• 使用微软的Anti-XSS组件来实现过滤
• 或
• 使用Anti-XSS SRE(Security Runtime Engine)实现全自动的过滤(用了HttpModule来过滤)
Broken Authentication and Session Management
• 标示session的cookie设置为HttpOnly Cookie
• Session, Cookie, Cache设置过期时间
• 不使用cookieless模式
• 注销动作需要销毁所有和session相关的设置，比如cache, cookie等
Insecure Direct Object References
• 在url中，不能看到能猜测的key，比如数据库中的自增长id，比如看到3，很容易猜测下个是4，尽量使用guid，考虑到int类型的primary key在数据库分析中的方便性，所以同时增加int和guid类型的primary key
• 业务对象表：技术主键ID（Int）+对外引用ID(Guid)
• application layer: 增加一些HashTable==> Guid-->Int 对应关系全局缓存, 程序设计中在Get/Update/Delete方法中需要注意同步这些key
Cross-Site Request Forgery (CSRF)
• 只用于post请求，对于get请求无效
• 使用于post操作中，比如我可以将一个aspx页面save as到本地进行修改，比如去掉js验证、修改HiddenField的value等，然后把form的action改为目标url，当submit这个 form后就不会validate，直接post到目标网址了，如果对方也没有在服务器端验证，不正常的数据就加入到数据库中（或者支付金额等。。。）；由于ViewState有效、事件验证也有效，所以需要额外处理
– 自定义ViewState
– 使用HttpModule方式，Monitor每个post请求，在每个请求中，设置一个额外的cookie，当post操作时用来监测是否有效请求（httpmodule会在每次请求页面时判断cookie的value和server side的context.Items的value是否一致）
• 自定义ViewState
– 默认的ViewState是没有加密的，可以通过下载一个叫ViewStateDecoder的工具能看到ViewState中保存的信息；可以给整个site写一个BasePage, 在里面设置ViewStateUserKey为per session的一个value，这样每个session的ViewState加密都不同
Security Misconfiguration
• 报错之后的重定向配置--〉CustomError
• Config文件的加密
– 使用命令行，如(run as admin)： C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -site "VulnerableApp" -app "/" -pe "connectionStrings"
Insecure Cryptographic Storage
• 对称加密配合随机的PasswordSalt参数
• 加密算法尽量使用DES等，因为SH1、MD5加密已经被认为破解了
Failure to Restrict URL Access
• 使用给每个aspx页面写basepage以达到对每个页面进行权限判断
• 页面上要对可做/不可做的操作/布局进行控制
• 给具体的函数贴上权限限制的tag，如：
– [PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
– public void RemoveUserFromRole(string userName, string role)
– {
• Roles.RemoveUserFromRole(userName, role);
– }
Insufficient Transport Layer Protection
• SSL保护
• HttpOnly Cookie
• Secure Cookie
• Web.config中相应设置cookie的配置
– <httpCookies requireSSL="true" />
– <httpCookies httpOnlyCookies="true" />
• 具有敏感信息的页面需要使用ssl保护
Unvalidated Redirects and Forwards
• 针对每个需要重定向的url进行验证是否合法
– 使用白名单，在名单里面的才允许redirect