10个安全测试漏洞修复经验，你掌握几个
随着互联网技术的飞速发展，业务的开展方式更加灵活，应用系统更加复杂，也因此面临着更多的安全性挑战。安全测试是在应用系统投产发布之前，验证应用系统的安全性并识别潜在安全缺陷的过程，目的是防范安全风险，满足保密性、完整性、可用性等要求。日常测试过程中经常遇到开发同事来询问一些常见的配置型漏洞应该如何去修复，为了帮助开发同事快速识别并解决问题，通过总结项目的安全测试工作经验，笔者汇总、分析了应用系统的一些常见配置型漏洞并给出相应的修复建议，在这里给大家进行简单的分享。
一、Cookie缺少HttpOnly属性
漏洞描述
Cookie中的HttpOnly属性值规定了Cookie是否可以通过客户端脚本进行访问，能起到保护Cookie安全的作用，如果在Cookie中没有将HttpOnly属性设置为true，那么攻击者就可以通过程序（JS脚本、Applet等）窃取用户Cookie信息，增加攻击者的跨站脚本攻击威胁。窃取的Cookie中可能包含标识用户的敏感信息，如ASP.NET会话标识等，攻击者借助窃取的Cookie达到伪装用户身份或获取敏感信息的目的，进行跨站脚本攻击等。
修复建议
向所有会话Cookie中添加“HttpOnly”属性。
1）Java语言示例：
HttpServletResponse response2 = (HttpServletResponse)response;
response2.setHeader( "Set-Cookie", "name=value; HttpOnly");
2）C#语言示例：
HttpCookie myCookie = new HttpCookie("myCookie");
myCookie.HttpOnly = true;
Response.AppendCookie(myCookie);
3）VB.NET语言示例：
Dim myCookie As HttpCookie = new HttpCookie("myCookie")
myCookie.HttpOnly = True
Response.AppendCookie(myCookie)
二、加密会话（SSL）Cookie缺少secure属性
漏洞描述
对于敏感业务，如登录、转账、支付等，需要使用HTTPS来保证传输安全性，如果会话Cookie缺少secure属性，Web应用程序通过SSL向服务器端发送不安全的Cookie，可能会导致发送到服务器的Cookie被非HTTPS页面获取，造成用户Cookie信息的泄露。如果启用了secure属性，浏览器将仅在HTTPS请求中向服务端发送cookie内容。
修复建议
向所有敏感的Cookie添加“secure”属性。
1）服务器配置为HTTPS SSL方式；
2）Servlet 3.0环境下对web.xml文件进行如下配置：
<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>3）ASP.NET中对Web.config进行如下配置：
<httpCookies requireSSL="true" /> 4）php.ini中进行如下配置：
<httpCookies requireSSL="true" />或者
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure= false [, bool $HttpOnly= false ]]]] )或者
bool setcookie ( string $name [, string $value? [, int $expire= 0 [, string $path [, string $domain [, bool $secure= false [, bool $HttpOnly= false ]]]]]] )5）在weblogic中进行如下配置：
<wls:session-descriptor>
<wls:cookie-secure>true</wls:cookie-secure>
<wls:cookie-http-only>true</wls:cookie-http-only>
</wls:session-descriptor>三、缺少“Content-Security-Policy”头
漏洞描述
因Web应用程序编程或配置不安全，导致HTTP响应缺少“Content-Security-Policy”头，可能产生跨站脚本攻击等隐患，可能会收集有关Web应用程序的敏感信息，如用户名、密码、卡号或敏感文件位置等。
修复建议
将服务器配置为使用安全策略的“Content-Security-Policy”头。
1）在web.config 配置文件中添加如下HTTP响应头：
<system.webServer>
<httpProtocol>?
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self';"/>
</customHeaders>
</httpProtocol>
</system.webServer>2）使用meta标签：
<meta http-equiv=”Content-Security-Policy” content=”default-src ‘self’”/>四、缺少“X-Content-Type-Options”头
漏洞描述
因Web应用程序编程或配置不安全，导致缺少“Content-Security-Policy”头，可能产生偷渡式下载攻击等隐患。
修复建议
将服务器配置为使用值为“nosniff”的“X-Content-Type-Options”头。
1）在web.config 配置文件中添加如下响应头：
<add name="X-Content-Type-Options" value="nosniff"/>2）使用meta标签
<meta http-equiv=”X-Content-Type-Options” content=”nosniff” />五、缺少“X-XSS-Protection”头
漏洞描述
因Web应用程序编程或配置不安全，导致缺少“Content-Security-Policy”头，可能产生跨站脚本攻击等隐患。
修复建议
将服务器配置为使用值为“1”（已启用）的“X-XSS-Protection”头。
1）在web.config 配置文件中添加如下响应头：
<add name="X-XSS-Protection" value="1;mode=block"/>2）使用meta标签
<meta http-equiv=”X-XSS-Protection” content=”1;mode=block” />六、缺少“HTTP Strict-Transport-Security”头
漏洞描述
因Web应用程序编程或配置不安全，导致缺少 HTTP Strict-Transport-Security 头。为了用户体验，有些网站允许使用HTTPS和HTTP访问，当用户使用HTTP访问时，网站会返回给用户一个302重定向到HTTPS地址，后续访问都使用HTTPS协议传输，但这个302重定向地址可能会被劫持篡改，被改成一个恶意的或者钓鱼HTTPS站点，导致敏感信息如用户名、密码、卡号或敏感文件位置泄露等风险。
修复建议
通过向 web 应用程序响应添加“Strict-Transport-Security”响应头来实施 HTTP 严格传输安全策略，或实施具有足够长“max-age”的 HTTP Strict-Transport-Security 策略，强制客户端（如浏览器）使用HTTPS与服务器创建连接。
七、容易出现点击劫持（Clickjacking）
漏洞描述
页面未能设置适当的X-Frame-Options或Content-Security-Policy HTTP头，则攻击者控制的页面可能将其加载到iframe中，导致点击劫持攻击，此类攻击属于一种视觉欺骗手段，主要实现方式有两种：一是攻击者将一个透明的iframe覆盖在一个网页上，诱使用户在该页面上进行操作，那么用户就在不知情的情况下点击透明的iframe页面；二是攻击者使用一张图片覆盖在网页，遮挡网页原有位置的含义。
修复建议
应用程序应该返回名称为X-Frame-Options、值DENY以完全防止成帧的响应头，或者返回值SAMEORIGIN以允许仅通过与响应本身相同的来源上的页进行成帧，或者通过ALLOW-FROM origin设置白名单来限制允许加载的页面地址。
1）修改中间件配置：
a）IIS：
web.config 配置文件中添加如下响应头：
<add name="X-Frame-Options" value="SAMEORIGIN"/>b）Apache：
Header always append X-Frame-Options SAMEORIGIN
c）Nginx：
add_header X-Frame-Options SAMEORIGIN;
2）使用meta标签
<meta http-equiv=”X-Frame-Options” content=”SAMEORIGIN” />八、启用了不安全的HTTP方法
漏洞描述
Web服务器或应用服务器以不安全的方式进行配置，导致启用了WebDAV和不安全的HTTP方法，不安全的HTTP方法一般包括：TRACE、PUT、DELETE、COPY等，可能会造成攻击者在Web服务器上上传、修改或删除Web页面、脚本和文件的隐患。
修复建议
禁用WebDAV。禁止不需要的HTTP方法（建议只使用GET和POST方法）。
1）Apache：
使用Apache的重写规则来禁用Options方法和Trace方法。在Apache配置文件httpd-conf中【vhosts-conf】添加以下代码：
#单独禁用Trace方法：
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK）
RewriteRule .* -
单独禁用Options方法：
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(OPTIONS)
RewriteRule .* -
同时禁用Trace方法和Options方法：
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
RewriteRule .* - <VirtualHost *:80>
DocumentRoot "D:\wwwroot"
ServerName www.abc.com
ServerAlias abc.com
<Directory "D:\wwwroot">
Options FollowSymLinks ExecCGI
AllowOverride All
Order allow,deny
Allow from all
Require all granted
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
RewriteRule .* -
</Directory></VirtualHost>2）Nginx：
在server段里加入下面代码：
if ($request_method !~* GET|POST) {
return 403;
} 重启Nginx，就可以屏蔽GET、POST之外的HTTP方法。
3）Tomcat：
修改web.xml配置文件。
<system.webServer> <security> <requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true"/>
<add verb="POST" allowed="true"/>
</verbs>
</requestFiltering> </security></system.webServer>九、"X-Powered-By"字段泄露服务器信息
漏洞描述
因Web服务器、应用服务器配置不安全，导致响应报文的响应头中"X-Powered-By"字段泄露服务器信息，攻击者可以通过获取服务器版本信息，收集相关漏洞，进行特定的攻击。
修复建议
隐藏响应头中"X-Powered-By"字段。
1）IIS：
修改web.config配置文件。
<configuration>
<location>
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
</configuration> 2）Nginx：
需要加上proxy_hide_header。
location / {
proxy_hide_header X-Powered-By;
}3）WAS：
修改websphere相应配置，将com.ibm.ws.webcontainer.disabledxPoweredBy配置更改为true。
十、"Server"字段泄露服务器信息
漏洞描述
因Web服务器、应用服务器配置不安全，导致响应报文的响应头中"Server"字段泄露服务器信息，攻击者可以通过获取服务器版本信息，收集相关漏洞，进行特定的攻击。
修复建议
隐藏HTTP响应头中"Server"字段，在web.config添加以下配置：
<system.webServer>
<modules>
<add name="CustomHeaderModule" type="StrongNamespace.HttpModules.CustomHeaderModule" /> 以上就是笔者在实际项目测试过程中经常遇见的十类常见应用配置型漏洞描述及针对常见中间件的修复建议，希望能够帮助开发同事快速理解各类漏洞并找到对应的修复方式！
页:
[1]
