页面评论者ip抓包工具 一篇补齐你的Web安全知识死角

点击上方“共享Fintech” 可以订阅哦！

WEB安全漏洞

概述

Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果Java、PHP、ASP等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。

漏洞分类

01

SQL注入

SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。

而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。

SQL 防护

不要信任用户的输入: 对用户的输入进行校验，可以通过正则表达式，或限制长度；对进入数据库的特殊字符（'，"，\，，&，*，; 等）进行转义处理，或编码转换。

不要使用动态拼装 SQL，可以使用参数化的 SQL 或者直接使用存储过程进行数据查询存取。

不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

不要把机密信息直接存放，加密或者 hash 掉密码和敏感的信息。

严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害

在应用发布之前建议使用专业的 SQL 注入检测工具进行检测，以及时修补被发现的 SQL 注入漏洞。网上有很多这方面的开源工具，例如 sqlmap、SQLninja 等。

不要过于细化返回的错误信息，如果目的是方便调试，就去使用后端日志，不要在接口上过多的暴露出错信息页面评论者ip抓包工具，毕竟真正的用户不关心太多的技术细节，只要话术合理就行。

当采用MyBatis执行sql语句时，存在模糊查询的方法。存在表达式${} 和 #{}

02

XSS 攻击

XSS 又称为 CSS，全程为 Cross-site script，跨站脚本攻击，为了和 CSS 层叠样式表区分所以取名为 XSS，是 Web 程序中常见的漏洞。

其原理是攻击者向有 XSS 漏洞的网站中输入恶意的 HTML 代码，当其它用户浏览该网站时候，该段 HTML 代码会自动执行，从而达到攻击的目的，如盗取用户的 Cookie，破坏页面结构，重定向到其它网站等。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。

根据攻击的方式，XSS攻击可以分为三类：反射型XSS、存储型XSS、DOM Based XSS。

反射型XSS也被称为非持久性XSS,这种攻击方式把XSS的Payload写在URL中，通过浏览器直接“反射”给用户。这种攻击方式通常需要诱使用户点击某个恶意链接，才能攻击成功。

存储型XSS又被称为持久性XSS,会把黑客输入的恶意脚本存储在服务器的数据库中。当其他用户浏览页面包含这个恶意脚本的页面，用户将会受到黑客的攻击。一个常见的场景就是黑客写下一篇包含恶意JavaScript脚本的博客文章，当其他用户浏览这篇文章时，恶意的JavaScript代码将会执行。

DOM Based XSS 是一种利用前端代码漏洞进行攻击的攻击方式。前面的反射型XSS与存储型XSS虽然恶意脚本的存放位置不同，但其本质都是利用后端代码的漏洞。

反射型和存储型xss是服务器端代码漏洞造成的，payload在响应页面中，DOM Based中，payload不在服务器发出的HTTP响应页面中，当客户端脚本运行时（渲染页面时），payload才会加载到脚本中执行。

XSS防御

常见的Web漏洞，如XSS、SQL注入等，都要求攻击者构造一些特殊的字符串，而这些字符串是一般用户不会用到的，所以进行输入检查就很有必要了。

输入检查可以在用户输入的格式检查中进行。很多网站的用户名都要求是字母及数字的组合如“1234qwer”，其实也能过滤一部分的XSS和SQL注入。但是，这种在客户端的限制很容易被绕过，攻击者可以用JavaScript或一些请求工具，直接构造请求，想网站注入XSS或者SQL。所以，除了在客户端进行格式检查，往往还需要在后端进行二次检查。客户端的检查主要作用是阻挡大部分误操作的正常用户，从而节约服务器资源。

在输出数据之前对潜在的威胁的字符进行编码、转义是防御XSS攻击十分有效的措施。

为了对抗XSS,在HtmlEncode中至少转换以下字符：

< 转成 <

> 转成 >

& 转成 &

“ 转成 "

‘ 转成 '

XSS防护—Spring MVC

a)项目级过滤

defaultHtmlEscape

true

b)页面级过滤

在包含form的jsp页面中添加

c)表单元素级过滤

在form元素中添加

或

03

CSRF

CSRF（Cross-Site Request Forgery），中文名称：跨站请求伪造攻击那么 CSRF 到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。

所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。

CSRF流程

角色

流程

1.用户登录、浏览并信任正规网站WebA页面评论者ip抓包工具，同时，WebA通过用户的验证并在用户的浏览器中产生Cookie。

2.攻击者WebB通过在WebA中添加图片链接等方式诱导用户User访问网站WebB。

3.在用户User被诱导访问WebB后，WebB会利用用户User的浏览器访问第三方网站WebA，并发出操作请求。

4.用户User的浏览器根据WebB的要求，带着步骤一中产生的Cookie访问WebA。

5.网站WebA接收到用户浏览器的请求，WebA无法分辨请求由何处发出，由于浏览器访问时带上用户的Cookie，因此WebA会响应浏览器的请求，如此一来，攻击网站WebB就达到了模拟用户操作的目的。

CSRF攻击防护

CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。服务端的预防 CSRF 攻击的方式方法有多种，但思路上都是差不多的，主要从以下两个方面入手：

一般而言，普通的 Web 应用都是以 GET、POST 请求为主，还有一种请求是 cookie 方式。我们一般都是按照如下规则设计应用的请求：

当正确的使用了 GET 和 POST 请求之后，剩下的就是在非 GET 方式的请求中增加随机数，这个大概有三种方式来进行：

CSRF 的防御可以根据应用场景的不同自行选择。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。

04

DDos

DDos又叫分布式拒绝服务，全称Distributed Denial of Service，利用DDos造成的攻击称为拒绝服务攻击，其原理就是利用大量的请求造成资源过载，导致服务不可用。

DDos攻击从层次上可分为网络层攻击与应用层攻击，从攻击手法上可分为快型流量攻击与慢型流量攻击，但其原理都是造成资源过载，导致服务不可用。

网络层DDos攻击

网络层DDos攻击包括SYN flood、UDP flood、ICMP flood等。

网络层DDos防御

网络层的DDos攻击究其本质其实是无法防御的，我们能做得就是不断优化自身的网络架构，以及提升网络带宽。

应用层 DDoS

应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。应用层攻击千变万化，目的就是在网络应用层耗尽你的带宽，下面列出集中典型的攻击类型。

应用层DDos防御

应用层的防御有时比网络层的更难，因为导致应用层被dos攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。而应用层DDos防御的核心就是区分人与机器（爬虫），因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

05

目录遍历漏洞

目录遍历漏洞成因：服务器端，接收请求中传来的文件名称，在服务器端拼凑成文件的绝对路径，并且用输出流下载。

防御措施

06

业务安全

在Web系统中，除了常规的如SQL，XSS，CSRF、Ddos等web漏洞外，更重要的是其业务上的安全。

账户信息安全

账户是一个系统的入口，关系到用户最直接的利益，因而账户的安全在业务安全中占及其重要的地位。账户体系分多个层次，每个环节的漏洞，都将给用户带来极大的损失。

业务数据安全

金额数据篡改：抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。

商品数量篡改：抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。

业务流程安全

顺序执行缺陷

部分网站逻辑可能是先A过程后B过程然后C过程最后D过程。

用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是，用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。

最后提交新密码时修改用户ID为其他ID

跳过验证步骤、找回方式，直接到设置新密码页面

业务接口安全

在短信、邮件调用业务或生成业务数据环节中（类：短信验证码，邮件验证码，订单生成，评论提交等），对其业务环节进行调用（重放）测试。如果业务经过调用（重放）后被多次生成有效的业务或数据结果

07

编程规范

08

总结

程序猿们能够管理好代码隐私，注意代码安全问题，比如不要将产品的含有敏感信息的代码放到第三方外部站点或者暴露给外部用户，尤其是前端代码，私钥类似的保密性的东西不要直接输出在代码里或者页面中。也许还有很多值得注意的点，但是归根结底还是绷住安全那根弦，对待每一行代码都要多多推敲。

开发时要提防用户产生的内容，要对用户输入的信息进行层层检测

要注意对用户的输出内容进行过滤(进行转义等)

重要的内容记得要加密传输(无论是利用https也好，自己加密也好)

get请求与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。

对于URL上携带的信息，要谨慎使用。

心中时刻记着，自己的网站哪里可能有危险。

系统安全人人有责

▼

作者介绍

李伟山

江湖人称：山哥，85年生产，IT届的小学生。享米高级技术总监，曾经在华为、阿里巴巴任职。

座右铭：Fake it until you make it。

欢

迎

关

注

共享金融科技平台

Fintech