网站建设常见的Web安全问题及防御策略

通过一个安全检查(过滤，净化)的过程，可以梳理未知的人或物，使其变得可信任。被划分出来的具有不同信任级别的区域，我们成为信任域，划分两个不同信任域之间的边界，我们称之为信任边界。数据从高等级的信任域流向低等级的信任域，是不需要经过安全检查的;数据从低等级的信任域流向高等级的信任域，是需要经过信任边界的安全检查。
安全问题的本质是信任的问题。一切的安全方案设计的基础，都是建立在信任关系上的。我们必须相信一些东西，必须要有一些最基本的假设，安全方案才能得以建立。

安全的三要素是安全的基本组成元素，分别为：机密性。机密性要求数据内容不能泄露，加密是实现机密性要求的常见手段。如果不将文件存在抽屉里，而是放在透明的盒子里，那么虽然无法得到这个文件，但是文件的内容将会被泄露。完整性。完整性则要求保护数据内容是完整，没有被篡改的。常见的保证一致性的技术手段是数字签名。可用性。可用性要求保护资源是“随需而得”。举例来说，假如有100个车位，有一天一个坏人搬了100块大石头将车位全占了，那么停车场无法再提供正常服务。在安全领域中叫做拒绝服务攻击，简称DoS(Denial of Service)。拒绝服务攻击破坏的是安全的可用性。

Secure By Default原则。实际上，Secure By Default原则，也可以归纳为白名单，黑名单的思想。如果更多地使用白名单，那么系统就会变得更安全。

最小权限原则。最小原则要求系统只授予主体必要的权限，而不要过度授权，这样能有效地减少系统，网络，应用，数据库出错的机会。如果网站只提供Web服务，只允许开启80，443端口，屏蔽其它端口。
纵深防御原则。要在各个不同层面，不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体;要在正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。
数据与代码分离原则这一原则适用于各种由于“注入”而引发安全问题的场景。实际上，缓冲区溢出，也可以认为是程序违背了这一原则的后果——程序在栈或者堆中，将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安全问题的发生。
不可预测性原则。微软使用的ASLR技术，在较新版本的Linux内核中也支持。在ASLR的控制下，一个程序每次启动时，其进程的栈基址都不相同，具有一定的随机性，对于攻击者来说，这就是“不可预测性”。不可预测性，能有效地对抗基于篡改，伪造的攻击。不可预测性的实现往往需要用到加密算法，随机数算法，哈希算法，好好利用这条规则，在设计安全方案时往往会事半功倍。
常见WEB安全问题。XSS (Cross Site Script)，跨站脚本攻击，因为缩写和 CSS (Cascading Style Sheets) 重叠，所以只能叫 XSS。
XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型：
非持久型XSS。也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。
持久型XSS。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。
未经验证的跳转XSS。一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感(cookie)信息。
CSRF。CSRF(Cross-Site Request Forgery)，名为：跨站请求伪造攻击。
那么 CSRF 到底能够干嘛呢?你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计。例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。
CSRF 攻击必须要有三个条件 :
1. 用户已经登录了站点 A，并在本地记录了 cookie
2 . 在用户没有登出站点 A 的情况下(也就是 cookie 生效的情况下)，访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
3 . 站点 A 没有做任何 CSRF 防御
预防 CSRF。CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。服务端的预防 CSRF 攻击的方式方法有多种，但思路上都是差不多的，主要从以下两个方面入手 :一方面是正确使用 GET，POST 请求和 cookie；另一方面在非 GET 请求中增加 token。
CSRF 的防御可以根据应用场景的不同自行选择。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。
SQL 注入。SQL 注入漏洞(SQL Injection)是 Web 开发中最常见的一种安全漏洞。攻击者利用这个漏洞，可以访问或修改数据，或者利用潜在的数据库漏洞进行攻击。
而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。
CSRF 攻击如何预防呢？防止 SQL 注入主要是不能允许用户输入的内容影响正常的 SQL 语句的逻辑，当用户的输入信心将要用来拼接 SQL 语句的话，我们应该永远选择不相信，任何内容都必须进行转义过滤，当然做到这个还是不够的，下面列出防御 SQL 注入的几点注意事项：
严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而大限度的减少注入攻击对数据库的危害;后端代码检查输入的数据是否符合预期，严格限制变量的类型，例如使用正则表达式进行一些匹配处理;对进入数据库的特殊字符('，"，\，<，>，&，*，; 等)进行转义处理，或编码转换;所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。
DDoS 攻击。DDoS 又叫分布式拒绝服务，全称 Distributed Denial of Service。其原理就是利用大量的请求造成资源过载，导致服务不可用，这个攻击应该不能算是安全问题，这应该算是一个另类的存在，因为这种攻击根本就是耍流氓的存在，是“伤敌一千，自损八百”的行为。DDos 攻击从层次上可分为网络层攻击与应用层攻击，从攻击手法上可分为快型流量攻击与慢型流量攻击，但其原理都是造成资源过载，导致服务不可用。
主要分类：网络层的 DDoS 攻击究其本质其实是无法防御的，我们能做得就是不断优化服务本身部署的网络架构，以及提升网络带宽。应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。
应用层的防御有时比网络层的更难，因为导致应用层被 DDoS 攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。
而应用层 DDoS 防御的核心就是区分人与机器(爬虫)，因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

新闻名称：网站建设常见的Web安全问题及防御策略
文章URL：http://mswzjz.cn/view/207386.html