| 背景
说来惭愧，6 年的 web 编程生涯，一直没有真正系统的学习 web 安全知识（认证和授权除外），这个月看了一本《Web
安全设计之道》，书中的内容多是从微软官方文档翻译而来，这本书的含金量不高，不过也不能说没有收获，本文简单记录一下我学习
Web 安全方面的笔记。
本文不涉及 IIS、Windows 和 SqlServer 的安全管理与配置，尽量只谈编程相关的安全问题。
最简单的 Web 物理架构
您必须了解 HTTP 协议，可以阅读这篇文章：HTTP 协议详解，简单总结如下：
浏览器和服务器的通信采用无状态的 HTTP 协议。
通过控制 HTTP 的请求头，可以控制：客户端缓存、Cookie、请求编码、相应编码等。
请求内容向服务器提交数据（POST 和 GET），响应内容向浏览器发送数据。
Cookie 包含在每个请求和响应中，因此客户端和服务器都可以访问到。
一般使用 Cookie 来维护一个浏览器会话（也有其他方式）。
攻击方式总览
Web 软件安全攻击防护
浏览器安全攻击
1、Cookie 假冒
定义
非期望的修改 Cookie 的值。
场景
服务器将用户的授权信息存储在 Cookie 中，然后客户端用这些 Cookie 决定导航的显示与否。如果有程序恶意的修改了Cookie，会导致权限提升。
攻击方式
1.注入的 Javascript 代码。
2.使用浏览器调试工具。
3.本机病毒等。
防护措施
1.尽量将 Cookie 设置为 HttpOnly，浏览器伪造不了这种
Cookie。
2.防止 Javascript 注入。
2、隐藏变量修改
定义
非期望的修改隐藏变量。
场景
订单的折扣计算完全依赖客户端的某个变量，这个变量是从服务器生成的，所有逻辑都在客户端计算，服务器只是接受最后的计算结果。如果有程序恶意的修改了变量，会绕过某些业务逻辑。
攻击方式
1.注入的 Javascript 代码。
2.使用浏览器调试工具。
保护措施
1.防止 Javascript 注入。
2.关键的功能不要依靠客户端控制，要采用服务器控制。
3、跨站脚本攻击
定义
恶意的提交 Javascript 代码。
场景
在博客的评论功能中，如果用户恶意的提交 Javascript 代码，假如这些 Javascript 没有被过滤，极端的情况下，这些代码会劫持所有访问此页面用户的会话，访问和修改任意数据。
攻击方式
1.注入的 Javascript 代码。
2.使用浏览器调试工具。
保护措施
1.在服务器端验证和过滤恶意输入。
2.开启 ValidateRequest="true"。
3.对输出使用 this.Server.HtmlEncode。
服务器安全攻击
1、缓冲区溢出
定义
某些可能输入会导致服务器堆栈溢出，这直接致使服务器不可用。
场景
程序提供了某项计算密集型的功能，此功能没有限制用户输入，用户在有意或无意之间输入了一个非法的值，导致了缓冲区溢出。
攻击方式
1. 非法输入。
保护措施
1.在服务器端验证和过滤恶意输入。
2.采用防伪式编程。
2、认证逃避
定义
某些 URL 没有出现在主页导航界面，系统只对导航页面进行了认证和授权管理，这些没有出现在导航中的 URL
可能被恶意用户给分析出来，直接进行访问。
场景
用户管理分为三个页面：List.aspx、New.aspx，程序只对 List.aspx 进行认证和授权了，某些用户直接访问
New.aspx 执行添加操作。
攻击方式
1.直接地址访问。
保护措施
2.梳理网站的整体结构，对所有页面进行认证和授权管理。
3、非法输入
定义
病从口入，祸从口出。很多攻击方式都是因为非法输入导致的。
场景
程序只在客户端对输入进行了验证，服务器未做任何验证，恶意的程序可以绕过客户端逻辑直接向服务器提交非法输入，这很容易导致各种安全问题。
攻击方式
1.注入的 Javascript 代码。
2.使用浏览器调试工具。
保护措施
1.在服务器端验证和过滤恶意输入。
2.防止 Javascript 注入。
4、授权逃避
定义
某些 URL 没有出现在主页导航界面，系统只对导航页面进行了认证和授权管理，这些没有出现在导航中的 URL
可能被恶意用户给分析出来，直接进行访问。还有一种可能是：系统只在客户端进行了授权管理，服务器代码并没有进行授权验证，恶意用户很容易就可以逃避授权。
场景
当用户没有 Create 权限的时候，系统只是禁用了浏览器按钮，并没有做服务器授权，然后用户使用浏览器调试工具启用了按钮，就可以执行
Create 了。
攻击方式
1.直接地址访问。
2.修改客户端代码。
保护措施
1.梳理网站的整体结构，对所有页面进行认证和授权管理。
2.在服务器进行授权管理。
5、SQL 注入
定义
对于和后台数据库产生交互的网页，如果没有对用户输入数据的合法性进行全面的判断，就会使应用程序存在安全隐患。用户可以在可以提交正常数据的URL或者表单输入框中提交一段精心构造的数据库查询代码，使后台应用执行攻击着的SQL代码，攻击者根据程序返回的结果，获得某些他想得知的敏感数据，如管理员密码，保密商业资料等。
场景
服务器程序使用字符串拼接的方式来构造 SQL 语句，这就会导致 SQL 注入攻击的可能。
攻击方式
1. 恶意的提交 SQL 片段。
保护措施
1.在服务器端验证和过滤恶意输入。
2.不要拼凑 SQL 参数，采用 DbParameter 设置参数。
3.最小化 SQL Server 访问账户的权限。
6、异常敏感信息泄露
定义
未处理异常直接显示到浏览器，这会导致敏感信息被泄露，对最终用户来说，也会让他们感觉系统不够安全和易用。
场景
因为开发原因，在某些场景下浏览器将后端的异常直接显示给浏览器了，如：NullReferenceException等。
攻击方式
1.在调用的最上层，为处理掉全部异常。
2.在调用的下层，为封装合适的异常信息。
保护措施
1.定义合理的异常处理策略。
2.异常一定不能跨越边界直接显示到浏览器。
7、上传攻击
定义
用户恶意的上传外挂、木马和其它程序等。
场景
你做了一个上传功能，结果对上传的文件没有做好足够的控制，比如：某些恶意的用户会上传一些恶意的脚本，然后执行这些脚本。
攻击方式
1.上传恶意文件。
保护措施
1.在服务器端验证和过滤恶意输入，如：后缀名限制。
2.对上传后的文件进行扫描和杀毒。
8、抵赖
定义
某些用户由于某些原因，不愿意承认自己执行过某些操作，当然，某些操作可能是他们没有意识的情况下执行的。
场景
用户一不小心执行的删除操作，然后立即发现自己操作错误了，然后他打电话给售后，说系统有问题。
攻击方式
1.界面引导不够友好，容易导致误操作，为了推卸责任，进行抵赖。
2.用户恶意的执行操作，然后抵赖。
保护措施
1.提高界面的易用性。
2.关键操作的提醒要足够明显。
3.所有操作要留下操作日志。
数据库安全攻击
1、连接字符串暴漏
定义
数据库连接字符串中包含用户名和密码，这些信息以明文的形式存储在配置文件中，运维和开发人员都能看得到，随着团队人员的流动，这些敏感信息也会暴漏。
场景
直接将连接字符串配置在 Web.Config 中，而这个文件没有被加密。
攻击方式
1.未加密连接字符串。
2.未加密配置文件。
保护措施
1.加密连接字符串。
2.加密配置文件。
2、存储数据泄露和篡改
定义
某些敏感信息最终需要被存储在数据库中，如果这些信息被存储为明文，会有很多人员可以看到这些信息，极端情况下，某些黑客攻陷了服务器，也可以看到这些数据。
场景
为加密密码、关键财务信息，税务局来查账了。
攻击方式
1.未加密敏感数据。
2.加密方法过于简单。
保护措施
1.加密敏感数据。
2.对某些数据采用不可逆加密，如：密码。
3.对某些数据采用可逆加密，如：财务数据。
网络安全攻击
1、拒绝服务攻击
定义
恶意用户试图攻击服务器、网络和系统，最终的目的是让系统不可用，停止对外服务。
场景
恶意用户在尝试并发的无限制的向服务器发送请求，试图让服务器的负载达到最大，最终让系统停止对外服务。
攻击方式
1.攻击网络。
2.攻击服务器。
3.攻击系统。
保护措施
1.在程序级别，识别并拦截恶意的请求。
2.购买第三方安全软件。
2、传输数组泄露、篡改
定义
恶意的代理服务器或路由器拦截用户的请求，读取或修改敏感数据。
场景
您在咖啡馆发现了一个免费的 WIFI，然后偷偷的接入了，您还暗自高兴，当您使用这个免费的 WIFI 进行网上冲浪的时候，您的各种信息都会被
WIFI 给拦截，如果是恶意的用户，结果可想而知。
攻击方式
1.绑架路由器。
2.免费 WIFI 骗局。
3.为加密的传输协议。
4.未加密的传输数据。
保护措施
1.加强客户端路由的安全管理。
2.慎重的选择代理服务器。
3.使用安全的传输协议，如：SSL。
|
