常见的几种web攻击的防范办法 web常见攻击方式

Web应用安全：那些你必须防范的常见攻击手段

Web应用的“体质”其实远比我们想象的要脆弱，针对它的攻击手段往往也足够直接和简单。今天，我们就来系统梳理几种最常见的Web攻击方式，并探讨如何正确地为你的应用构筑防线。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

SQL注入攻击

说起Web安全，SQL注入是个绕不开的“老话题”。但凡用过Ja va的开发人员，第一个想到的防御措施多半是使用预编译的PreparedStatement，对吧？

什么是SQL注入攻击

简单来说，就是攻击者瞅准机会，在HTTP请求中偷偷塞入恶意SQL代码。当服务器使用这些参数拼接数据库SQL命令时，恶意代码就被一并构造并执行了。

举个典型的例子：用户登录时，输入用户名“lianggzone”，密码却填成了 ' or '1'='1。如果后端采用简单的字符串拼接方式构造SQL，最终执行的语句就会变成：

select * from user where name = 'lianggzone' and password = '' or '1'='1'

瞧，这样一来，无论用户名和密码是什么，查询条件 '1'='1' 永远为真，导致能查询出用户列表，从而绕过登录验证。

现在还会存在SQL注入攻击么？

说起来，使用了预编译的PreparedStatement后，安全性确实得到了质的提升。但现实情况可能没这么乐观，很多项目由于开发人员不够重视，依然会留下漏洞。不信？你可以留心观察一下，代码里对于SQL中的IN操作，究竟是用预编译的占位符，还是依旧在偷偷进行字符串拼接呢？

如何防范SQL注入攻击

使用预编译的PreparedStatement无疑是必须坚守的底线。但完善的防范通常需要双管齐下：

Web端：进行输入的有效性检验，比如限制字符串输入的长度。
服务端：这是防守的重中之重。首先，绝对避免拼接SQL字符串，坚持使用预编译。其次，服务端必须再次进行有效性检验——请记住安全第一准则：外部输入皆不可信，必须防止攻击者绕过前端直接发起请求。最后，过滤SQL参数中的特殊字符，比如单引号、双引号，也是常规操作。

XSS攻击

那么，什么是XSS攻击呢？它的全称是跨站脚本攻击。攻击者通过篡改网页内容，嵌入恶意脚本程序。当用户浏览这个被“污染”的网页时，脚本就会在用户浏览器中悄悄执行，从而实施恶意操作。

假设页面上有一个表单

如果用户输入的不是一个正常名字，而是一段特殊代码：

"/>
那么，渲染后的页面就会变成这样，输入框后面被“嫁接”上了一段脚本：


上面这个脚本仅仅是弹个窗，危害不大。但攻击的威力完全取决于输入的内容，只要稍加修改，破坏力就可能急剧上升。

XSS攻击有多可怕？
早些年，我曾随手测试过几个网站，发现大家对XSS的防范普遍不足，测试脚本很容易就被注入成功。更有甚者，攻击者会在评论或反馈区提交恶意的Ja vaScript代码（如果这些区域的客户端未做XSS校验，就会存在注入点）。这样一来，所有访问该页面的用户，都会在不知不觉中执行那段恶意代码。

如何防范XSS攻击
防御XSS也需要前后端协同作战。一方面，前后端都要对字符串输入的长度进行限制。另一方面，更关键的是，前后端都必须对内容进行HTML转义处理，将“<”、“>”这类特殊字符转换为HTML实体，让它们被当作纯文本显示，而非可执行的代码。

CSRF攻击
接下来是跨站点请求伪造，即CSRF攻击。攻击者会跨站发起请求，并以合法用户的身份进行非法操作。可以这么理解：攻击者盗用了你的身份，用你的名义去向第三方网站发送恶意请求。它能干的事可不少，比如用你的账号发邮件、发信息、转账，甚至盗取账号信息。

如何防范CSRF攻击
主流防御手段有这么几种：一是引入安全框架，比如Spring Security。二是采用Token机制，在HTTP请求中加入令牌验证，如果请求中没有Token或Token不正确，就视为CSRF攻击并拒绝。三是使用验证码，这通常能有效遏制CSRF，但出于用户体验考虑，它更多作为辅助手段。四是Referer识别，通过HTTP头中的Referer字段判断请求来源，如果来自其他网站则可能拒绝。但这种方法有局限，因为很多用户会出于隐私考虑屏蔽Referer，或者浏览器在某些情况下（如HTTPS跳HTTP）也不会发送它。

文件上传漏洞
什么是文件上传漏洞？简单说，就是用户上传了一个可执行的脚本文件，并利用它获得了在服务端执行命令的能力。这可是个大杀器。
历史上，许多第三方框架和服务都曾曝出过此类漏洞，比如早期的Struts2以及一些富文本编辑器。一旦被攻击者上传了恶意代码，服务器很可能就此沦陷。

如何防范文件上传漏洞
防范措施必须严格：首先，文件上传的目录应设置为不可执行，从根源上杜绝脚本运行。其次，判断文件类型时要格外小心，应结合MIME Type、文件内容特征和后缀名进行综合校验。因为攻击者很容易将可执行文件的后缀改为图片等格式来骗过检查。第三，建立上传文件类型的白名单，只允许可靠的类型通过。第四，对上传的文件进行重命名，让攻击者无法预测文件的访问路径，能极大增加攻击成本。像“shell.php.rar.ara”这种嵌套扩展名的文件，也会因重命名而失效。第五，限制上传文件的大小。最后，如果条件允许，将文件服务器部署在独立的域名下，也是一种有效的隔离策略。

访问控制
在Web安全中，“基于URL的访问控制”是最常见的模型，但它通常需要细分为垂直和水平两个维度。

垂直权限管理
这其实就是建立用户与权限之间的对应关系，业内常称之为“基于角色的访问控制”（RBAC）。不同角色权限有高低之分，高权限访问低权限资源通常被允许，反之则被禁止。配置权限时，务必遵循“最小权限原则”，并采用“默认拒绝”的策略——只对有明确需要的主体单独配置“允许”策略。这能有效避免“越权访问”。像Spring Security、Apache Shiro这类框架都能很好地帮助构建垂直权限体系。

水平权限管理
水平权限问题则更为隐蔽。系统只验证了访问数据的角色，却没有对同一角色下的不同用户做进一步细分。由于这是系统缺乏数据级访问控制造成的，所以它也被称为“基于数据的访问控制”。
举个例子：假如一个产品的评论删除功能，只校验了用户是否登录，却没有校验“当前用户是否只能删除自己的评论”。那么，恶意用户通过修改评论ID，就能删除他人的评论，这就造成了危险的越权操作。
这个层面的安全，通常需要在业务逻辑代码中精细处理。遗憾的是，它恰恰是最容易被遗漏的安全环节之一。

总结
上面探讨的这些话题，都是Web开发过程中高频出现的安全隐患及其防范思路。安全问题必须由我们在开发阶段就主动规避，而不能指望安全人员、用户甚至攻击者来帮我们发现漏洞。当然，Web安全的领域远不止这些，还有远程执行漏洞、拒绝服务攻击、Session固定攻击等等。如果读者对安全领域有更深入的兴趣，强烈推荐阅读吴翰清的《白帽子讲Web安全》，这本书非常值得一读。

推荐文章：
多层防护机制应对防范勒索软件的威胁
详解网络安全：不仅要通过去，还要晓未来
详解与DirectAccess有关的10件事情