相信大家都或多或少的听过关于各种Web应用安全漏洞，诸如：跨site脚本攻击(XSS)，SQL注入，上传漏洞……形形色色。

    在这里我并不否认各种命名与归类方式，也不评价其命名的合理性与否，我想告诉大家的是，形形色色的安全漏洞中，其实所蕴含安全问题本质往往只有几个。 我个人把Web应用程序安全性本质问题归结以下三个部分：

    1、输入/输出验证(Input/output validation)

    2、角色验证或认证(Role authentication )

    3、所有权验证(Ownership authentication)

    说到这，读者一定想知道我这三种分类与形形色色的安全性问题有什么关系？下面我逐个给您概略解答：

    输入/输出验证

    这里的输入与输出其实都是发生在用户界面（User Interface）这一个层面上的，比如：你某一站点上提交一份注册信息，往往会收到诸多提示：“用户名非法”，“姓名不能使用英文“……其实这就是输入验证的一个实例。什么情况是输出呢？比如说你成功提交一份注册信息后，系统会返回一个确认页（Registerred Confirmation），往往在这个页面上会显示你注册时提交的部分或全部信息，那么在这里显示的信息就是我所说的输出实例之一，输入需要做什么验证？

    假如你在提交时，在Address那一栏输入：

    <script>alert("iwebsecurity");</script>

    当你到达注册的确认页时，会有什么发生？如果确认页没有做输出验证处理，那很显然会在到达确认页的时候出现一个Javascript打出的提示框。其实这就是跨site脚本攻击的一个小小的实例。当然了，单纯的输入／输出验证涉及的面可能够写一小本书了，努力在后续文章中给大家详解。

    角色验证或认证

    我们就拿CSDN来说吧，用户有这些角色：其一可以说是游客，就是浏览者没有登录时的角色；其二是免费的注册用户；或许将来CSDN深入发展了，业务有所更新，还会出现收费的注册用户。以上只是用户角色，那在CSDN公司内部还会有管理员角色，还有可能管理员又可以根据板块分为各种不同的角色。大家看到了吧，你天天访问的CSDN一共可能有多少角色？接下来的问题就是权限问题了，为什么会有角色？就是为了控制权限的。每种角色都有自己特定的与公共的权限，这些权限的逻辑关系是相当复杂的，如果一个Web应用在角色上没有一个详细的合理的设计，将会给开发人员带来无限痛苦和麻烦。那现在我要问几个问题：你能保证每种角色只能做其份内的事儿？你是如何去保证的呢？方法可靠吗？有没有漏洞？……这，就是我要说的角色验证或认证。BTW：为什么我会说验证或认证呢？你可以这么理解，角色性存在于两个阶段，其一进入阶段，比如你登录的那一瞬间，你进入了一个特定的角色；另一个阶段就是维持阶段，你如何确保你登录后总是以登录时的身份在操作呢？那前者可以说是：认证，后者就是验证了。

    给一个角色认证／验证方面的虚拟案例，比如：一个在线电影服务提供商，会免费给您开一个试用角色，如果这试用角色验证不当，可能会导致用户权限提升而成为一个合法的收费用户，而这个收费用户你往往却收不到他的任何费用。

    所有权验证

    这个问题的存在也是基于角色的，只不过它所关心的是同级别的角色之间的权限问题。就拿CSDN来说吧，我是CSDN的一个免费用户，你也是。

    现在的问题是：我可以替你操作吗，我可以替你发表文章吗？我能修改你的个性设置吗？如果不能，CSDN是如何实现的？虽然你和我都是普通用户，但是你有你的隐私我也有我的隐私，如何保证严格的所有权验证就显得尤为关键了。比较简单吧，这就是我所说的所有权验证。

    我可以很自信的告诉你，只要是Web应用安全性问题，它逃不出在这三大部分，可能你还无法把形形色色的Web应用安全性问题与这三个部分对应并合理的解释清楚，但是确实只有这么简单的几个部分。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。