目录
1.1、简介：
由于客户端组件和用户输入不在服务器的直接控制范围内， Web应用程序的核心安全面临威胁。对于服务器来说，客户端及其提交的所有数据从本质上讲都不值得信任
2.1、简介：
少数应用程序存在缺陷都有一个原因， 那就是因为它们通过客户端以危险的方式传送产品价格和折扣率之类的重要数据。
应用程序会尽可能避免通过客户端传送这类数据。在条件允许的情况下， 都可以将这类数据保存在服务器上， 并在必要时通过服务器端逻辑直接引用。
2.2、示例：
接受用户购买各种产品而提交的订单的应用程序应允许用户提交产品代码和数量， 并在服务器端数据库中查询每一种产品的价格。用户没有必要向服务器提交产品价格。即使应用程序向不同的用户提供不同的价格或折扣， 也不必抛弃这种模型。
价格可按用户分类保存在数据库中， 而折扣率则保存在用户资料或会话对象中。应用程序已经拥有计算某一特殊用户所购买的某种产品的价格所需的一切信息——在不安全的类型中， 它必须将这个价格保存在一个隐藏的表单字段中。
对于在ASP.NET平台上运行的应用程序而言，不会将任何定制数据以及任何不希望在屏幕上向用户显示的敏感数据保存在ViewState中。会总是激活用于启用ViewState MAC的选项。
2.3、分析：
如果要通过客户端传送送要数据， 那么会对数据进行签名、加密处理以防止客户端用户篡改
可能会面临的重要的威胁：
1、签名或加密数据可能易受重传攻击
例如， 如果在将价格保存到隐藏表单之前对其进行加密， 攻击者就可以用一个更加便宜的产品的加密价格代替最初的产品价格。为防止这种攻击， 应用程序需要在加密数据中包含足够的上下文， 以防止攻击者在另一种情况下重新传送产品价格。例如， 应用程序可以将产品代码和价格组合在一起，将得到的字符串单独加密， 然后确认随订单提交的加密字符串是否与被订购的产品完全匹配。
2、密钥破解
如果用户知道并能够控制送交给他们的加密字符串的明文值， 那么就可以实施各种密码攻击， 找出服务器使用的加密密钥。之后， 他们就能够用密钥加密任意值， 完全避开解决方案提供的保护
3.1、示例：
1、客户端无法安全确认由客户端生成并且向服务器传送的数据
2、可轻易避开HTML表单字段和JavaScript之类的轻量级客户端控件， 无法保障服务器收到的输入的安全性。
3、在浏览器扩展组件中执行的控件有时更难以避开， 但这种控件只能暂时阻止攻击者入侵
4、使用经强化模糊处理或压缩的客户端代码增添了另一层障碍，蓄意攻击者还是能够克服这些障碍。（其每一种新型解决方案通常在不久后就被攻破。）
确认客户端生成数据的唯一安全方法是在应用程序的服务器端实施保护。客户端提交的每一项数据都应被视为危险和潜在恶意的
3.2、优点：
1、客户端脚本可用于确认输入， 以提击可用性， 避免与服务器来回通信。
2、客户端数据确认可以与安全措施一样有效
3、许多方法可通过客户端传送加密数据， 而不会遭到破坏或重传攻击
4.1、简介：
应用程序采用长度限制和基于JavaScript的确认之类的机制来提高性能与可用性，这些机制应与服务器端入侵检测防御工具组合使用。对客户端提交的数据进行确认的服务器端逻辑应认识到，客户端也采用了同样的确认机制。
4.2、示例：
如果服务器收到已被客户端阻止的数据， 应用程序可能会据此推断，用户正设法避开这种确认， 因此这些数据可能是恶意的。应用程序应将异常记录到日志中， 适当情况下向应用程序管理员发出实时警报， 以便他们能够监控任何攻击企图，并在必要时采取适当的行动。应用程序还会主动采取防御措施， 终止用户会话或者暂时冻结其账户。
注：有的情况，虽然用户的浏览器禁用JavaScript ， 但仍然能够使用使用JavaScript的应用程序。
因为浏览器完全忽略了基于JavaScript的表单确认代码， 提交的是用户输入的原始信息，为避免错误警报，日志与警报机制应了斛这种情况会在什么地方出现， 会如何发生