目前的网络攻击主要还是以WEB攻击为主流，毕竟这是与外界沟通获取知识和了解世界的主要桥梁。
目前随着各大企业对安全的重视，Web的攻击成本逐渐高于了防御成本，导致业务中Web安全漏洞的逐渐减少，甚至常规漏洞的消亡。当然，一个漏洞的消亡必会有新的漏洞或者攻击手法的出现，攻击的入门门槛随之而然逐渐的提高。攻防只有前进，没有倒退，即使目前Web安全的攻击成本高于防御成本，防御Web攻击的软件再多，我们也不能放松每一个防御点。
Web攻击现状
DDoS攻击和Web应用攻击是当今互联网面临的较为突出的两大安全威胁，DDoS是非漏洞型攻击，我们暂且不谈。Web应用攻击占了网络攻击的主流，由于其地位，这是事实。由于目前国内某些原因，导致以前以技术为主导的现状不在，现在相对于过去封闭，当前往往一个新的攻击手法出现，很长时间都没有人知道，只在某一小圈子里流传。所以在Web防御逐渐完善的过程中，我们可以感觉的到，渗透一个网站越来越吃力，而是Web这个东西，目前已知的漏洞挖掘方向点就那么多，针对这些漏洞点的防御软件又多如牛毛，防御者把这些走已知常规漏洞路给堵死了，一般的攻击者可能无能为力，但是对于一些高水平的攻击者来说，也许并不是无路可走。
所以，依照现状来看，目前的Web漏洞利用走向开始往逻辑漏洞方面走，如黑产最喜欢的薅羊毛就是一个例子，现在想要拿到Web站点服务器系统权限不容易，不过利用逻辑漏洞拿到用户数据信息倒是不难。目前常规的攻击手法已很难能够攻破防护做的比较好的企业，所以，为了了解最新攻击技术或漏洞，我们需要搭建蜜罐系统来捕获攻击样本，获取自家产品的0day漏洞或更新现有落后技术。
常见漏洞防护
一些常规的漏洞防护就不说了，防护的软件已经有很多了，漏洞扫描器都可以扫出来，扫不出来的，好一点的防护软件也是可以识别的。按道理来讲，我们应用部署安全监控软件是可以防护常见漏洞的，当然，我们企业自身也可以通过漏洞攻击指纹进行攻击特征识别，攻击者绕过防护软件进行攻击这个也是我们防护不了的也是不可避免的，只要按照标准化安全编程手册，出现常规漏洞的点会很少，至少显性漏洞不可见。这里主要讲讲逻辑漏洞问题。
逻辑问题层出不穷，其他的常规漏洞防范已经有了规范化流程，而逻辑漏洞到目前还没有一个流程化的防护方案，因为其特殊性，所以我们也得特殊对待。
逻辑漏洞常出现在用户交互和信息展示之处，当然还有与系统进行交互的地方，下面列几点
验证码
验证码是我们常见的一种应对暴力攻击的方式之一，主要是为了区分人和非人的产物，验证码经历了多次改版，几乎每个网站的验证码都不尽相同，验证码在应对绕过和攻击识别时变得越来越复杂，用户体验也越来越不好。
拿以前的12306的验证码为例。
请点击下面所有的熟鸡蛋，鬼都不知道哪个鸡蛋是熟鸡蛋，怎么猜?
当然了，这个只是个笑话，但是也恰恰说明了问题，我们不仅要做好验证码，而且还要让用户不感到体验效果差。
验证码经过了长期的变化，目前主要分为以下这几类，我们来了解下
静态验证码
此类验证码是比较古老的，应该说是最初的验证码了，静态验证码从以前的文本型过度到了现在的图片型，虽然目前静态验证码加了很多抗干扰加花等等操作，但是目前能够识别静态验证码的手段还是很多的，大多数的静态验证码比较容易被ocr软件识别，通过打码平台等，还有就是当前火热的机器学习，通过训练机器，其静态验证码的识别率可以达到80%以上，所以现在很多站点都开始弃用此类验证码了
Gif动画验证码
有的网站提供GIF动态的验证码图片，由于在Gif验证码中，有多个验证码图层，这些都是随机的，使得识别器不容易辨识哪一个图层是真正的验证码图片，可以更有效得防止识别器的识别。但是也是有弊端的，Gif在显示的最后都会暂停供用户识别，只要识别出最后暂停的那张图层，就可以像识别静态验证码那样识别Gif验证码了。
手机短信验证码
手机验证码是通过发送验证码到手机，这个是比较好的验证手段，目前使用这类验证码的站点还是很多的。
手机语音验证码
这个验证码的成本比较高，一般用于金融等站点的验证码，不过效果还是很好的。
视频验证码
视频验证码中随机组合而成的验证码动态嵌入到MP4，flv等格式的视频中，增大了破解难度。验证码视频动态变换，随机响应，可以有效防范字典攻击、穷举攻击等攻击行为。攻击者可以通过抓屏的方式进行识别，但是效果不是很好。
滑动验证码
这种验证码是最近几年流行起来的，这个验证码需要与用户进行交互，采用拼图或滑动左右模式进行验证。应对此类验证码攻击者一般是通过网站的验证码接口找突破，或者采用如鼠标模拟等操作进行验证码识别。
点击验证码
此类验证码一般是给出一张图片让用户进行识别，如12306的验证码识别。应对此类验证码攻击者一样可以通过鼠标模拟等操作进行验证码识别。
智力验证码
顾名思义就是，给用户出一道题，让用户把答案算出来进行验证。此类验证也是存在一定的弊端的，因为验证码大多数是以图片的形式出现的，而相对于比较低级的算数题类验证码，攻击者可以用静态验证码识别的手段进行问题提取，继而进行算数运算，从而达到识别此类验证码的目的。
交互验证码
此类验证应该算是目前前端验证码验证比较安全的验证码了。
在有客户端的站点上应用比较广泛，首先要登录站点，需要客户端进行授权，如扫码登录，客户端验证后，服务端把登录信息发送前端进行登录操作。
当然还有其他的验证码验证手段，这里就不一一介绍了，具体使用什么验证码还得看站点的特性和业务的类型，没全有最好最安全的验证码，只有最适合的验证码。
交互逻辑
交互逻辑漏洞虽然不像常规漏洞那么厉害，可以直接拿下系统权限，但是给企业造成的损失却是很大的。我们经常可以看到一些新闻，说某某网站由于出现支付漏洞，导致损失多少钱。因为逻辑漏洞是不可避免的，它不像常规漏洞可以容易的被漏洞扫描器扫出，它更多的是需要测试人员代码审计或黑盒测试找出。所以这个交互逻辑漏洞也是比较难以防控的一个点。
通常出现交互逻辑漏洞的点为登录处、支付处、用户信息交互处和与数据库交互处。因为网站程序的某些交互接口或者数据交互接口信息验证逻辑问题，对提交的数据参数审计不严格，造成交互逻辑漏洞，下面列出比较常见的交互逻辑漏洞。
登录交互逻辑
在登陆处，一般的测试会测试站点是否严格控制登录交互，
攻击者通过抓包查看提交参数，查看是否有可以利用的交互逻辑漏洞，有些站点在登录参数，也就是帐号密码传过来后，会验证帐号密码是否正确，然后返回true或者返回false，即使使用错误的帐号密码，当返回false时，那么我们就可以改返回数据包为true，那么就直接登录了，更有胜者当用户名正确后，无论密码是否正确，都直接返回正确的帐号密码。有人可能会想，即使你改掉包，不是还有cookie或者token吗?话虽没错，但是某些站点的cookie是直接在前端生成，或者在我们改掉包后，服务器端会把正确的cookie给你返回回来。
还有在找回密码处，通过找回密码这个交互逻辑漏洞，攻击者可以重置任意账户密码，从而达到自己的目的，这对于金融行业和电商行业等用户量大的站点，造成用户信息泄漏或者资金被盗甚至对用户造成诈骗等后果，这对企业的声誉和发展都会造成影响和损失。
在找回密码处，攻击者一般通过验证邮箱或者手机号找回密码，如果帐号匹配，服务器一般会发送短信验证码或者邮箱验证码到用户手里，那么这个过程如果服务器端验证不严格就有可能会造成交互逻辑漏洞的发生。
重置密码的攻击逻辑常见的有如下几点
- 攻击者通过修改返回包，绕过验证步骤，直接到达修改密码处
- 攻击者通过修改返回包，把当前重置帐号(如手机号，邮箱地址)，修改为自己的帐号(如手机号，邮箱地址)，那么在服务器没有对帐号进行严格验证的情况下，服务器端会直接把重置验证凭证发送到攻击者的手里
- 攻击者通过抓取返回包，由于服务器端的自身逻辑问题，可能会把帐号密码等等与当前重置帐号的相关信息给返回过来，不用重置，就知道了用户密码
- 站点找回密码设计问题，当重置密码后，服务器会发送新的密码到用户手中，而这个密码是几位的纯数字，攻击者是可以通过暴力穷举的方式知道重置的密码，更有趣的是，某些站点直接是重置密码为固定的密码字符串
- 网页验证不严格，可通过url直接到达修改密码处
- 某些通过邮件找回的，其重置密码的链接是可以猜测和预知的
还有就是验证码逻辑问题，某些验证码虽然在前端进行了验证，但是在后端却没有进行很严格的检查，攻击者可以通过删除验证码或者验证码是不变的，可有可无的，那么攻击者就可以实施撞库或这暴力破解用户帐号密码了。在用手机或邮箱或其他接收攻击接收登录或重置密码时，可能出现验证码交互逻辑漏洞。我们知道，一般情况下，站点发送的验证码是有时间限制的，通常为几分钟，如果验证码在后端发送逻辑有问题的话，就会出现问题。如，当攻击者在爆破时，验证码过期时间为5分钟，时间快到了时，攻击者再发送一次请求，因为后端没有做失效控制策略，就又会收到一次一模一样的验证码，而且时间又是5分钟，那么想要爆破某一个帐号的密码就不再是什么难事了。当然还有站点直接返回验证码的，或者验证码是在前端生成通过后端直接发送到用户手中的。
想要防护登录交互逻辑此类的漏洞也很简单，就是要对相关的参数做个严格的验证，如
- 登录的逻辑不返回前端，由后端管控，前端进行调用
- 验证码失效时间进行严格控制，验证码不能多次使用，为一次性验证码，获取验证码的时间也要有时间限制，由后端管控，预防被用于短信轰炸
- 所有的账户重置信息都不返回给前端
- 生成的重置密码连接是不可预知的，随机的
当然，防护手端多种多样，最主要的只有一点，那就是严格检查参数，对参数进行严格的校检，预防此类漏洞就只能是提高验证逻辑。
支付逻辑
支付漏洞可以说是比较严重的逻辑漏洞了，毕竟是涉及到钱这个问题。一个支付漏洞有可能会对企业造成巨大的损失。
支付漏洞的产生符合逻辑漏洞特点，都是其修改自身逻辑达到欺骗的效果。
支付的一般流程为：确认信息=>提交订单=>支付=>支付成功
主要的漏洞点如下
1.修改参数属性值
参数的属性值有
- 支付金额
- 代金卷
- 积分
- 其他
这几个属性值也是最为基础和常见的支付逻辑漏洞发生点，攻击者一般的攻击手法为修改支付金额的多少来进行测试，出现漏洞的支付步骤一般在提交订单时或提交订单之后，通过把支付的金额修改成低价格或者修改为负数，如果后端判断逻辑有问题，那么就会出现支付逻辑漏洞了。
所以，在后端进行判断时，要对相关参数进行绑定，即使在前端修改了，后端也是可以初始化参数的。
2.修改数量值
这个和修改参数属性值差不多，也是把商品数量修改为负数达到支付金额成负数的效果，当然还有一种就是商品差价修改，用一种低价格商品的数量总金额去支付高价格商品的数量总金额，如果后端逻辑有问题，那么就可以低价格购买高价格商品了。
3.越权支付
越权一般发生在支付环节，攻击者可以通过修改自身ID为其他用户的ID值，如果没有严格的支付密码或验证码的话，就可以达到用他人账户为自己的商品买单的效果，当然还有其他的越权支付手段，如越权支付他人账单，越权提现他人现金等。
4.条件竞争
条件竞争这个词我们在Web漏洞或是其他系统漏洞中都是可以看到的，条件竞争利用其高并发线程，利用时钟延迟(后台处理延迟)达到多出或或高于现有正常结果。如LFI漏洞，通过不断写入tmp文件，达到getshell的目的。同样，如提现功能来说，如果我们把要提现的金额分成多份，通过高并发线程，如果后端处理能力或者逻辑判断能力存在缺陷的话，那么我们就可以提现高于提现次数的金额。
5.支付状态
通常在我们支付成功后，服务器会返回一个支付成功或支付失败的结果，如果在后端没有对支付状态和订单号进行绑定的话，那么攻击者只需要修改返回状态为True就会成功购买商品，而无论支付是否成功。
支付逻辑漏洞主要是代码层方面的防护，如果后端对提交的参数进行了绑定，那么无论前端怎么的修改，后端都是可以判断和初始化参数的;对于支付接口来说，如果调用第三方支付接口的话，也是要对接口进行绑定，最好对订单号进行绑定，避免用不存在的支付接口支付成功。
对于此类支付漏洞来讲，我们能做的就是提高风控手段，所有的支付结果要进行延时处理，把支付结果与订单之前的结果进行对比，查看是否异常，必要时加入人工审核，以此来减小事故发生几率。
越权
对于越权，越权也是属于逻辑漏洞的一种。
越权漏洞的存在环境，在Web环境中的不同而不同，拿有登录操作的站点来聊聊。在这类站点中，越权一般出现在个人信息处，如我们点击个人信息，通常在个人信息链接数据包里会带有用户userid，不出意外的话，我们修改其userid为其他用户userid会出现其他用户的信息。这个漏洞的产生是后端对用户的权限或登录状态判断不严造成的，对于此类漏洞站点一般的做法是添加用户token或附带其他什么乱七八糟的验证，对于越权也算是比较好的防范了。
当然，逻辑漏洞远不止上面提到的这么多，逻辑漏洞的防范是一个长期的过程，随着站点的业务和功能的拓展，其逻辑复杂度也在增加，只要企业把控好权限、验证、输出这三个点，逻辑漏洞出现的几率也就小了许多。
系统错误配置
某些站点的安全管控做的非常好，但是细节却处理的不好，其中不乏一些大的厂商，站点不出现漏洞，但是支持站点运行的服务器软件由于站点管理员的违规操作可能会导致大的漏洞产生。如Apache开放了PUT功能，权限管控不到位所导致的目录遍历操作，IIS的短文件名漏洞等。所以按照规范定期进行服务器基线检查是非常有必要的。
数据库漏洞
数据库漏洞一般就是弱口令或未授权访问，其余的如REC等漏洞或多或少还是需要点权限的，随着企业的安全意识提高，建站一般会使用站库分离的做法，这样做可以很好的保护数据库服务器和提高站点服务器的系统资源利用率，提高站点安全性。当然，站点的权限如非必要，最好还是进行降权账号登录，很多的数据库漏洞都是因为暴露在公网导致的被入侵，如果权限较低的话，那么被攻下的难度就很高了。
从站点的SQL注入漏洞来讲，这本身就不属于数据库漏洞了，属于站点自身的漏洞，所以SQL注入的根源在于站点代码，而非数据库。
薅羊毛
薅羊毛这个虽不能算是漏洞(也可以说和漏洞危害差不多)，但是对企业造成的损失还是很大的，目前薅羊毛现已经成为了一个产业链，羊毛党利用网站漏洞或者人员条件(黑产)等其他优势，合法占用企业资源，使企业的宣传或活动达不到预期的效果，浪费企业资源，甚至造成损失。
当企业辛辛苦苦策划出来的活动被羊毛党利用，企业投入了大量物力换来的是羊毛党的流量，那么，我们有什么方法能减少被薅羊毛额几率呢?
防范羊毛党可以从以下几个方面着手
- 严控注册流程，阻止非法注册
- 定期清理垃圾帐号
- 提高参加活动的门槛
- 对参加活动的用户进行严格的资格审核，提高用户真实性
- 平台漏洞：严控相关活动的接口调用逻辑，确保通过了安全检测后上线
- 延迟活动奖励的时限
- 增加和提高合法用户真实性(人机用户)验证机制
当然，具体的防范措施也不是依照以上几种防范措施就能完全杜绝薅羊毛的行为，所谓完善的安全管控体系，都是建立在具体实践的基础上的，防范管控经验都是在经历了”具体事故“才能很完美的总结出来，这样才能对企业自身或者具体业务量身定制一套薅羊毛应对措施，往大了说还能通用于某一行业的所有产品。
第三方程序管控
一个企业里面，用到的Web程序不敢说都是自己开发的,或多或少会用到其他企业的开源或收费的Web程序，那么这些Web程序又该如何管控呢?
对于此类应用来说，上线和自身产品差不多，都是需要经过安全评估的，通过了安全评估以后，进行备案上线。后续需定期关注官网补丁并及时进行补丁更新，如果Web程序存在0day漏洞的话，结合当前服务器的安全策略进行管控。
权限管控
权限这个问题是站点被攻破后的最后一道防御点，如果站点权限出现问题，那么整个站点就真的沦陷了。
在Web的渗透测试中，攻击者在拿到了可以操控站点的权限时(如后台登录权限)，首先想到的就是上传脚本木马来控制服务器，然后利用脚本木马来进行提权操作，最后内网渗透等等。
所以在攻击者有了操作站点权限的这个节点时是企业管控Web这最后一道防线的关键点，下面我们来讨论下权限问题。
站点的启动一般不用最高权限启动，一般管理员会新建一个低权限的账号来启动Web站点服务，用低权限启动的Web服务权限有限，无法执行创建修改或删除文件等高权限操作，所以对脚本木马的写入有一定的防范作用;但是有一些站点因为要使用某些第三方库，或者需要执行某些合法的敏感操作，可能会要求请求高权限启动，这个时候权限管控就会有一定风险存在了，企业能做的就是对整个站点进行旁路权限管控，如：
- 上传目录的脚本解析和执行权限
- 站点的命令执行权限
- 跨目录权限
所以，权限最大的问题在于执行上，如果控制了执行权限，那么无论你怎么上传，上传什么文件，都执行不起来。
权限管控是一个老生常谈的问题，权限和业务有着比较矛盾的问题，因为有些情况下需要开启高权限来支撑站点的某一功能，但是在该功能的高权限开启情况下又会出现安全问题。所以说，权限管控并不难，难就难在要配合具体业务场景而又不要出现安全问题上。
日常监控
监控站点是一种了解当前站点运行状态的必要手段，也是一种获取攻击和威胁情报的来源之一。
监控的手段一般为
- 日志监控
- 通信流量监控
- 文件监控
- 系统操作监控
通过监控手段，企业可以获取大量有用的信息，能够帮助企业改善产品、获取威胁情报、调查取证等方面有着很大的帮助。
日志监控主要是针对于Web服务器和站点所产生的日志情况，提取日志中所产生的异常并针对性的进行处理。
通信流量监控主要是针对Web站点的所有流量进行的监控，在通信流量里面一般会包含攻击行为，那么对于匹配性的攻击行为进行预警，筛选出攻击流量进行分析，如果可靠的话，我们有一定的几率可以获得新的攻击技巧、0day漏洞或者发现站点新的漏洞等。对于某些攻击流量来说，一个站点存在命令执行，在流量中会出现系统命令或其他第三方命令等特征字符。
文件监控是站点监控里比较重要的监控之一了，因为攻击者攻击站点时一般都会对文件进行操作，文件的变动可以让被入侵的站点快速定位入侵点，从而应急及时，减小损失;文件监控对于权限管控不到位而造成的安全问题有着比较好的支撑，对于那些正常文件被写入脚本木马的文件来说，我们可以知道写入的代码是否为木马代码，是否为正常代码，是否为非法写入。
系统操作监控主要为针对Web站点所执行的系统操作，在系统操作监控里面，我们可以看到Web站点和系统的所有交互行为，通过监控日志，我们可以分析得出，Web站点的哪些文件在与系统进行交互，执行的行为是否为正当合法的行为(和syslog取证差不多)。
通过监控的手段，我们可以清楚的了解到站点服务器都做了些什么，它们所做的事情是否是正当的。监控手段所带来的好处就是，如果出现安全问题能够在第一时间找出问题所在，监控手段在检测到疑是攻击行为时，可以进行有效的攻击阻断，即使是Web站点存在漏洞情况下。这一点就和WAF的功能有相识之处了。
WAF
权限管控是Web安全的最后一道防线，那么WAF(Web Application Firewall)可以说是Web安全中的第一道防线。
在目前互联网的Web站点中，无论网站大小或多或少会安装WAF来保护网站，在安装了WAF的网站比不安装WAF的网站安全性要高，站点安装了WAF提高了攻击的门槛，可以防范一般的(没有什么技术能力的)攻击者。随着技术的发展和安全攻防的交锋加剧，WAF的功能也从以前的功能单一逐渐变为现在的多功能WAF，不仅能够拦截过滤还能杀毒等。
当然，不得不说的就是现在常用的加速器CDN(Content Delivery Network)了，CDN发展也是差不多，以前只是单一个给网站加个速，发展到现在，CDN有了WAF的功能，能够代替WAF做一些攻击拦截的事情，当然不是有了CDN就能完全代替WAF了，如果攻击者绕过了CDN找到了服务器的真实IP地址呢，又当如何?
在Web安全的建设中，WAF不能说必不可少，但是有了WAF，站点的安全性能够提高到一个档次，不仅能够挡掉一些普通攻击者的攻击，还能够提高高级攻击者的攻击成本，即使网站沦陷了，不是还有其他的防护手段吗?都是摆设?没错，其他的防护手段就是摆设。
安全建设就是这样，防护做的再好，如果没有从根源解决问题，攻击者只要有心，那么一切的防护手段绕过只是时间问题，这个就和擒贼先擒王是一个道理了。所以，Web漏洞的根源就是站点代码，只要代码层显性漏洞不存在，加上代码层的其他安全防护措施做到位，那么站点就能做到相对安全，而能够让站点做到相对安全的就是“代码安全审计”。
代码安全审计
代码审计作为安全测试中重要的一环，代码审计能够发现一些潜在的漏洞，帮助企业更好的完善Web程序，减少被攻击的风险。
如上文所述，站点服务器的防护做的再好，如果站点的程序代码存在问题的话，那么一切的防护措施可能成为摆设。作为一个负责的企业，要对自己和自己的用户负责，那么Web产品在发布或新版本更新时，就需要进行代码审计，以最大的可能减小漏洞发生的几率。
对于Web程序来讲，代码审计一般特别针对常规高危漏洞，因为对于常规漏洞一般的扫描器都是可以扫的出来的，而对于那些需要特定条件才能触发的漏洞(如CSRF，埋雷攻击)，产品能做的就是尽可能的控制各个交互的权限分离和绑定(加强验证)。
目前市面上免费的和收费的代码审计产品有很多，大多数都是基于静态分析，所以误报率还是比较高的，审计工具它只能是个参考，具体的逻辑分析还是需要专业的安全技术人员跟进。那么代码审计也有一定的盲区，因为随着一个产品的功能增加，代码量的加大，有时候一个产品的代码就有几万行，大小几十上百兆，不可能说完全依靠人工能够审计的完的，就算审计完了，质量还是得不到保证。在这个情况下，工具就有了用武之地，代码审计可以以白加黑的方式进行，审计效率可以提升很多。
在我们代码审计无法触及之处，其余的漏洞就只能交由网络白帽子来进行发现了。
安全众测
众测是最近几年火起来的，在网上也有许多的众测平台，在这些平台上，企业可以花比较少的钱就能把Web安全做的上个大的档次。由于人的精力和攻击知识面不同，在企业内部代码审计和渗透测试无法再找到漏洞时，拿去进行一次众测，不出意外的话，一定可以收到不一样的效果。正所谓“山外青山楼外楼”，白帽子发现的漏洞和其独特的利用姿势可以作为Web产品安全的完善方向。而对于比较小型的网站来说，众测就显得没有什么必要了。
业务风控
一个web系统的安全性如果做的很好了，常规漏洞一般是不会出现的，那么由于攻击手法的不确定性，如果有新型的漏洞或者更高级的攻击手法出现，那么一个web系统将面临高风险。所以企业需要自身有一套完善的风控制度，一旦发生安全问题，能够在第一时间以最快速度解决问题，降低损失。整个风控的方面可以从：社会影响、内部影响、经济损失等方面着手，建立起完善的灾备恢复体系。着重加强纵深防御，防止外部威胁扩大到内部。
Web安全建设总结
在Web安全中，攻击利用的手法多变，它不像系统漏洞那样，只要管控好端口，那么远程攻击就会失效。Web虽然简单，但是漏洞的成因还是很复杂的，不是我们把可能存在的漏洞点堵上就能没事的，反之，Web以一个小小的错误都有可能会导致所有的防御失效。攻击者攻击Web程序只需要一个点，而防御者却需要防御的是整个面，在Web攻防中，一直以来Web的防御都是处于被动的局面，企业想要改变这一局面，只能是任重而道远。
鉴于Web漏洞防御和漏洞成因的复杂性，Web安全建设不是本篇文章能够说的清的，也不是企业把握好文章中的几个点就能把Web安全建设的好的，这样的话只能说笔者站着说话不嫌腰疼了。Web安全的体系建设不仅仅是安全漏洞的管控，当然还包括了其他的方方面面，攻击者可能利用合法的网站功能来干一些不可描述的事情，如果Web安全的建设是很简单的话，就不会出现众多安全专家都头疼的事情了。
所以，具体的Web安全建设各个企业不同，所属业务不同，自然所做的建设方案也会有所不同，能够建设起来非常棒的Web安全体系，企业都是经过了众多实践积累下来的经验。
不过，对于Web防御重要的几个点，倒还是比较通用的。
权限问题
权限在Web安全中是很重要的，因为攻击者有了操控站点的权限后，就会想方设法的拿到服务器的权限，进而完成更深入的渗透。权限的管控在于当前业务所属类型决定，权限分制能够让权限得到更好的管控。
主动防御问题
主动防御就是一些WAF等审计系统了，主动防御不是万能的，使用不当还可能会对自身业务产生影响，主动防御会被绕过的几率还是有的。
监控问题
监控这一部分是比较难的点，因为由于攻击手法的不确定性，监控规则不够灵活等方面，造成了监控可能会有遗漏的地方。
代码安全审计问题
代码的安全审计是Web安全之根本，如果没有审计过的程序上线的话，可能存在的高风险就会比审计过的程序多，所以，代码审计是Web程序正式发布版本前的必要工作。
