安全扫描五项简介_cve-2015-9251，重磅来袭

最新推荐文章于 2024-06-14 07:22:17 发布

Android失眠夜

最新推荐文章于 2024-06-14 07:22:17 发布

阅读量755

点赞数 12

分类专栏： 2024年程序员学习文章标签：安全网络 web安全

本文链接：https://blog.csdn.net/m0_61418075/article/details/137534999

版权

2024年程序员学习专栏收录该内容

233 篇文章

订阅专栏

本文介绍了网络安全的五个关键环节：代码检测、主机基线检查（包括nginx和麒麟系统）、WEB扫描、渗透测试及用户枚举漏洞的修复建议。此外，还提供了黑客学习资源，包括零基础入门的学习路线和视频教程，旨在帮助网络安全工程师提升技能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

安扫五项

项目安全检测一般分为五项：主机漏扫，主机基线，代码检测，渗透测试，web扫描

检测顺序，主机漏扫，主机基线，代码检测，渗透测试和web扫描（该两项在代码就检测修复或者没问题后进行，代码检测项目组完成）

1.代码检测

Java代码漏洞检测-常见漏洞与修复建议-CSDN博客

2.主机基线

nginx合规检查


日志审计	检查是否启用日志功能—记录访问日志
其它安全	检查是否限制客户端下载的并发连接数
检查是否配置防盗链接设置


描述	序号：检查点（结果）	标准值	实际值	配置方法
检查是否启用日志功能—记录错误日志	1:应配置日志功能对错误日志进行记录(是)	error_log	error_log /data/nginx/logs/error.log;	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，去掉error_log前面的"#"号
检查是否启用日志功能—记录访问日志	1:应设置access_log文件格式(否)	log_format		编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，设置access_log，去掉前面的注释，修改配置文件如下： log_format formatname ‘$remote_addr - $remote\_user [$ time_local] ’ ’ “$request” $status $body\_bytes\_sent "$ http_referer" ’ ’ “ $http\_user\_agent" "$ http_x_forwarded_for”’; access_log logs/access.log formantname; formatname是设置配置文件格式的名称
1:设备应配置日志功能，对访问日志进行记录(是)	access_log	access_log /data/nginx/logs/access.log;	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，去掉#access_log logs/access.log formatname;前面的"#"号 formatname是设置配置文件格式的名称
检查是否隐藏nginx版本信息	1:应修改nginx服务信息头内容，隐藏nginx版本信息(是)	server_tokens off;	server_tokens off;	修改nginx解压路径(eg:/usr/local/nginx-1.5.6/src/http/ngx_http_header_filter_module.c)文件的第48和49行内容，自定义头信息： static char ngx_http_server_string[] = “Server:XXXXX.com” CRLF; static char ngx_http_server_full_string[] = “Server:XXXXX.com” CRLF; 添加如下代码到nginx.conf(eg:/usr/local/nginx/conf/nginx.conf)配置文件，禁止错误页面中显示nginx版本号： server_tokens off; 注意，句尾的分号不能少
检查是否自定义错误信息	1:应自定义nginx返回的错误信息(是)	/^\s*error_page[\s\S]+/	error_page 500 502 503 504 /50x.html;	修改nginx_install_dir/conf/nginx.conf文件在每个站点server里添加自定义错误页面，例如： error_page 404 /404.html; 404.html为具体的自定义错误页面，需要放在站点的根目录下，一般是在nginx_install_dir/html/目录下配置完毕后采用nginx_install_dir/sbin/nginx -t测试配置文件是否正确。之后平滑重启nginx nginx_install_dir/sbin/nginx -s reload
检查是否控制超时时间—客户端保持活动的超时时间	1:设置客户端连接保持活动的超时时间(是)	/\d+\s\d/	65	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下： keepalive_timeout 5 5; #第一个参数指定客户端连接保持活动的超时时间，第二个参数是可选的，它指定了消息头保持活动的有效时间重新启动nginx服务需要根据应用场景的需要选择合适的参数值
检查是否控制超时时间—客户端请求读取超时时间	1:设置客户端请求头读取超时时间(是)	/\d+/	30	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下： client_header_timeout 10; #设置客户端请求头读取超时时间重新启动nginx服务需要根据应用场景的需要选择合适的参数值
1:设置客户端请求主体读取超时时间(是)	/\d+/	30	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下： client_body_timeout 10; #设置客户端请求主体读取超时时间重新启动nginx服务需要根据应用场景的需要选择合适的参数值
检查是否限制客户端下载的并发连接数	1:应设置存储session状态的容器(否)	limit_zone		编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下：例如网站存放路径为/usr/local/nsfocus/ ，服务器名称为：down.nsfocus.com http { …… limit_zone one $binary_remote_addr 10m; #针对每个IP定义一个存储session状态的容器，10m的容器按照32bytes/session，可以处理320000个session server { listen 80 server_name down.nsfocus.com; index index.html index.htm index.php; root /usr/local/nsfocus; #Zone limit; location / { limit_conn one 1; #限制每个ip只能发起一个并发连接 limit_rate 20k; #限制每个连接的限制速度为20K，IP的下载速度为连接数*限制速度 } ……… } 重启nginx服务根据应用场景的需要进行并发数、速度限制注： limit_zone 这个变量只能在http中使用 limit_coon和limit_rate变量可以在http,server,location中使用
1:应设置客户端下载的连接并发数（每个IP的连接并发数）(否)	/\d+/		编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下：例如网站存放路径为/usr/local/nsfocus/ ，服务器名称为：down.nsfocus.com http { …… limit_zone one $binary_remote_addr 10m; #针对每个IP定义一个存储session状态的容器，10m的容器按照32bytes/session，可以处理320000个session server { listen 80 server_name down.nsfocus.com; index index.html index.htm index.php; root /usr/local/nsfocus; #Zone limit; location / { limit_conn one 1; #限制每个ip只能发起一个并发连接 limit_rate 20k; #限制每个连接的限制速度为20K，IP的下载速度为连接数*限制速度 } ……… } 重启nginx服务根据应用场景的需要进行并发数、速度限制注： limit_zone 这个变量只能在http中使用 limit_coon和limit_rate变量可以在http,server,location中使用
检查是否控制超时时间—响应客户端的超时时间	1:设置响应客户端的超时时间(是)	/\d+/	30	编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置如下： send_timeout 10; #指定响应客户端的超时时间重新启动nginx服务需要根据应用场景的需要选择合适的参数值
检查是否配置防盗链接设置	1:应配置防止其他网站盗链本网站资源(否)	location ~* ^.+.		编辑nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf) 具体设置举例如下： location ~* ^.+.(gif

麒麟基线


检查项名	检查项类别	检查内容	检查说明
麒麟-检查是否禁止匿名用户登录FTP	协议安全	若vsfptd开启，/etc/vsftpd.conf或者/etc/vsftpd/vsftpd.conf中应存在anonymous_enable=NO and 禁止匿名WU-FTP用户登录	文件传输协议（FTP）支持网络计算机传输文件功能。
麒麟-检查是否修改snmp默认团体字	协议安全	检查是否安装snmp服务检查配置文件/etc/snmp/snmpd.conf是否存在。检查snmp团体字是否未使用public 检查snmp团体字是否未使用private	检查配置文件/etc/snmp/snmpd.conf是否存在检查snmp团体字是否未使用public 检查snmp团体字是否未使用private
麒麟-检查重要目录或文件权限设置	系统文件权限	检查以下文件权限是否符合规范： /etc/group文件权限是否符合规范 <= 644 /etc/shadow文件权限是否符合规范 <= 600 /etc/passwd文件权限是否符合规范 <= 644 /etc/rc.d/init.d/文件权限是否符合规范 <= 750 /etc/rc4.d文件权限是否符合规范 <= 750 /etc/rc3.d文件权限是否符合规范 <= 750 /etc/rc6.d文件权限是否符合规范 <= 750 /etc/rc0.d文件权限是否符合规范 <= 750 /etc/rc2.d文件权限是否符合规范 <= 750 /etc/rc5.d文件权限是否符合规范 <= 750 /etc/xinetd.conf文件权限是否符合规范 <= 600 /etc/services文件权限是否符合规范 <= 644 检查系统引导器配置文件权限 <= 600 /etc/rc1.d/文件权限是否符合规范 <= 750 /etc/security目录权限是否符合规范 <= 600	检查重要目录或文件权限设置
麒麟-检查使用IP协议远程维护的设备是否配置SSH协议，禁用telnet协议	协议安全	对于使用IP协议进行远程维护的设备，应配置使用SSH协议 and ( 对于使用IP协议进行远程维护的设备，应禁止使用telnet协议 or 是否存在telnet进程 )	检查使用IP协议远程维护的设备是否配置SSH协议，禁用telnet协议
麒麟-检查设备密码复杂度策略	配置PAM认证	检查密码复杂度是否设置种类为3或更复杂。	检查密码复杂度是否设置种类为3或更复杂。
麒麟-检查是否按用户分配账号	其他安全	检查是否按用户分配账号	用户账号唯一）应为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性。检查是否按用户分配账号。
麒麟-检查是否按组进行账号管理	其他安全	检查是否按组进行账号管理	确定账号属组）应确定系统账号属组是否正确，检查是否按组进行账号管理。
麒麟-检查口令最小长度	配置PAM认证	检查密码是否设置最小长度为6	pam_pwquality.so模块检查密码的强度。它执行检查，例如确保密码不是字典词汇，符合一定长度，包含字符（例如字母，数字，其他）等等的混合。
麒麟-检查命令行界面超时时间	其他安全	检查命令行界面超时时间	检查命令行界面超时时间
麒麟-检查是否配置用户所需最小权限	其他安全	检查/etc/passwd文件权限 and 检查/etc/shadow文件权限 and 检查/etc/group文件权限	检查是否配置用户所需最小权限
麒麟-检查root是否为唯一的UID为0用户	身份鉴别	检查是否存在除root之外UID为0的用户	确定账号属组）应确定系统账号属组是否正确。任何UID为0的账户都具有系统的超级用户权限。
麒麟-检查是否启用远程日志功能	日志	1 、判定条件设备配置远程日志功能，将需要重点关注的日志内容传输到日志服务器。 2 、检测操作查看日志服务器上的所收到的日志文件。 3 、补充说明	设备配置远程日志功能，将需要重点关注的日志内容传输到日志服务器。
麒麟-检查是否启用cron行为日志功能	日志审计	检查是否启用cron行为日志功能	检查是否启用cron行为日志功能
麒麟-检查是否启用系统日志功能	日志审计	检查是否启用系统日志功能	检查是否启用系统日志功能
麒麟- 检查是否设置口令生存周期	账号/密码要求	密码过期时间应：小于等于90天	密码过期时间允许管理员强制密码在达到定义的寿命后过期。
麒麟-检查是否设置口令过期前警告天数	账号/密码要求	口令过期前警告天数应：大于等于30天	检查口令过期前警告天数
麒麟-检查是否启用安全日志功能	日志审计	检查是否启用安全日志功能	检查是否启用安全日志功能

3.WEB扫描

威胁分类
信息泄露类型:资源位置可预测
信息泄露类型:信息泄露
命令执行类型:系统命令执行
逻辑攻击类型:拒绝服务
客户端攻击类型:内容欺骗

中级


漏洞名称	详细描述	解决办法	验证方法
检测到目标站点存在javascript框架库漏洞【可验证】	JavaScript 框架或库是一组能轻松生成跨浏览器兼容的 JavaScript 代码的工具和函数。如果网站使用了存在漏洞的 JavaScript 框架或库，攻击者就可以利用此漏洞来劫持用户浏览器，进行挂马、XSS、Cookie劫持等攻击。	将受影响的javascript框架库升级到最新版本。	根据检测到目标站点存在javascript框架库漏洞原理，通过获取javascript框架库版本并查看该版本是否在受影响范围内进行漏洞验证。参考验证：jquery:1.12.0 (Link) https://www.cvedetails.com/cve/CVE-2015-9251/
检测到目标主机可能存在缓慢的HTTP拒绝服务攻击	缓慢的HTTP拒绝服务攻击是一种专门针对于Web的应用层拒绝服务攻击，攻击者操纵网络上的肉鸡，对目标Web服务器进行海量HTTP请求攻击，直到服务器带宽被打满，造成了拒绝服务。慢速HTTP拒绝服务攻击经过不断的演变和发展，主要有三种攻击类型，分别是Slow headers、Slow body、Slow read。以Slow headers为例，Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部，因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点，发起一个HTTP请求，一直不停的发送HTTP头部，消耗服务器的连接和内存资源。抓包数据可见，攻击客户端与服务器建立TCP连接后，每10秒才向服务器发送一个HTTP头部，而Web服务器在没接收到2个连续的\r\n时，会认为客户端没有发送完头部，而持续的等等客户端发送数据。如果恶意攻击者客户端持续建立这样的连接，那么服务器上可用的连接将一点一点被占满，从而导致拒绝服务。这种攻击类型称为慢速HTTP拒绝服务攻击。	针对不同的Server其对慢速http拒绝服务攻击防范方法也不同，建议使用以下措施防范慢速http拒绝服务攻击： WebSphere ======== 1、限制 HTTP 数据的大小在WebSphere Application Server 中进行如下设置：任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。 HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。另一种常见的 DOS 攻击是发送一个请求，这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。设置限制任何请求正文的最大大小。 2、设置keepalive参数打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找KeepAlive值，改ON为OFF,其默认为ON。这个值说明是否保持客户与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。详见参考链接： http://www.ibm.com/developerworks/cn/websphere/techjournal/1210_lansche/1210_lansche.html#new-step32 Weblogic ============ 1、在配置管理界面中的协议->一般信息下设置完成消息超时时间小于200 2、在配置管理界面中的协议->HTTP下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。 http://docs.oracle.com/cd/E12890_01/ales/docs32/integrateappenviron/configWLS.html#wp1101063 Nginx ============ 1、通过调整$request_method，配置服务器接受http包的操作限制； 2、在保证业务不受影响的前提下，调整client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffersclient_body_timeout, client_header_timeout的值，必要时可以适当的增加； 3、对于会话或者相同的ip地址，可以使用HttpLimitReqModule and HttpLimitZoneModule参数去限制请求量或者并发连接数； 4、根据CPU和负载的大小，来配置worker_processes 和 worker_connections的值，公式是：max_clients = worker_processes * worker_connections。 Apache ============ 建议使用mod_reqtimeout和mod_qos两个模块相互配合来防护。 1、mod_reqtimeout用于控制每个连接上请求发送的速率。配置例如： #请求头部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slowloris型的慢速攻击。 RequestReadTimeout header=10-40,minrate=500 #请求正文部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slow message body型的慢速攻击。 RequestReadTimeout body=10-40,minrate=500 需注意，对于HTTPS站点，需要把初始超时时间上调，比如调整到20秒。示例： LoadModule reqtimeout_module modules/mod_reqtimeout.so <IfModule reqtimeout_module> RequestReadTimeout header=10-40,minrate=500 body=10-40,minrate=500 2、mod_qos用于控制并发连接数。配置例如： # 当服务器并发连接数超过600时，关闭keepalive QS_SrvMaxConnClose 600 # 限制每个源IP最大并发连接数为50 QS_SrvMaxConnPerIP 50 这两个数值可以根据服务器的性能调整。更多关于qos_module配置参考： http://mod-qos.sourceforge.net/dos.html 示例： LoadModule qos_module modules/mod_qos.so <IfModule qos_module> QS_SrvMaxConnClose 600 QS_SrvMaxConnPerIP 50 IHS服务器 ============ 请您先安装最新补丁包，然后启用mod_reqtimeout模块，在配置文件中加入： LoadModule reqtimeout_module modules/mod_reqtimeout.so 为mod_reqtimeout模块添加配置： <IfModule mod_reqtimeout.c> RequestReadTimeout header=10-40,MinRate=500 body=10-40,MinRate=500 对于HTTPS站点，建议header=20-40,MinRate=500。参见：http://www-01.ibm.com/support/docview.wss?uid=swg21652165 F5负载均衡修复建议 ============ F5负载均衡设备有相应的防护模块，如无购买可参考附件中的详细配置过程。关于F5的慢速攻击防护配置，请参考以下链接： https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html https://devcentral.f5.com/articles/mitigating-slow-http-post-ddos-attacks-with-irules-ndash-follow-up IIS服务器 ============ IIS可配置相关网站的Web.config如下： 1、WebLimits设置： <system.applicationHost> </system.applicationHost> 参考以下链接： https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/weblimits#configuration 2、headerLimits设置： <system.webServer> </system.webServer> 参考以下链接： https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/requestlimits/headerlimits/
检测到目标URL存在http host头攻击漏洞【可验证】	为了方便的获得网站域名，开发人员一般依赖于HTTP Host header。例如，在php里用_SERVER[“HTTP_HOST”]。但是这个header是不可信赖的，如果应用程序没有对host header值进行处理，就有可能造成恶意代码的传入。	web应用程序应该使用SERVER_NAME而不是host header。在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项。	根据检测到目标URL存在http host头攻击漏洞原理，通过修改host头并根据目标站点的响应情况进行漏洞验证。

低级


漏洞名称	详细描述	解决办法	验证方法
检测到目标X-Content-Type-Options响应头缺失【可验证】	X-Content-Type-Options HTTP 消息头相当于一个提示标志，被服务器用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型的设定，而不能对其进行修改。这就禁用了客户端的 MIME 类型嗅探行为，换句话说，也就是意味着网站管理员确定自己的设置没有问题。 X-Content-Type-Options响应头的缺失使得目标URL更易遭受跨站脚本攻击。	将您的服务器配置为在所有传出请求上发送值为“nosniff”的“X-Content-Type-Options”头。对于 Apache，请参阅： http://httpd.apache.org/docs/2.2/mod/mod_headers.html 对于 IIS，请参阅： https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx 对于 nginx，请参阅： http://nginx.org/en/docs/http/ngx_http_headers_module.html	根据检测到目标X-Content-Type-Options响应头缺失漏洞原理，通过从目标站点响应头信息中检查X-Content-Type-Options配置情况进行漏洞验证。
检测到目标X-XSS-Protection响应头缺失【可验证】	HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。 X-XSS-Protection响应头的缺失使得目标URL更易遭受跨站脚本攻击。	将您的服务器配置为在所有传出请求上发送值为“1”（例如已启用）的“X-XSS-Protection”头。对于 Apache，请参阅： http://httpd.apache.org/docs/2.2/mod/mod_headers.html 对于 IIS，请参阅： https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx 对于 nginx，请参阅： http://nginx.org/en/docs/http/ngx_http_headers_module.html	根据检测到目标X-XSS-Protection响应头缺失漏洞原理，通过从目标站点响应头信息中检查X-XSS-Protection配置情况进行漏洞验证。
检测到目标Content-Security-Policy响应头缺失【可验证】	HTTP 响应头Content-Security-Policy允许站点管理者控制用户代理能够为指定的页面加载哪些资源。除了少数例外情况，设置的政策主要涉及指定服务器的源和脚本结束点。 Content-Security-Policy响应头的缺失使得目标URL更易遭受跨站脚本攻击。	将您的服务器配置为发送“Content-Security-Policy”头。对于 Apache，请参阅： http://httpd.apache.org/docs/2.2/mod/mod_headers.html 对于 IIS，请参阅： https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx 对于 nginx，请参阅： http://nginx.org/en/docs/http/ngx_http_headers_module.html	根据检测到目标Content-Security-Policy响应头缺失漏洞原理，通过从目标站点响应头信息中检查Content-Security-Policy配置情况进行漏洞验证。
检测到目标URL存在电子邮件地址模式【可验证】	垃圾邮件程序会搜寻因特网站点，开始查找电子邮件地址来构建发送自发电子邮件（垃圾邮件）的邮件列表。如果检测到含有一或多个电子邮件地址的响应，可供利用以发送垃圾邮件。而且，找到的电子邮件地址也可能是专用电子邮件地址，对于一般大众应是不可访问的。	根据需求，从 Web 站点中去除无用电子邮件地址，使恶意的用户无从利用。	根据检测到目标URL存在电子邮件地址模式漏洞原理，通过从目标站点获取电子邮件地址进行漏洞验证。
检测到目标Referrer-Policy响应头缺失	Web 服务器对于 HTTP 请求的响应头中缺少 Referrer-Policy，这将导致浏览器提供的安全特性失效。当用户在浏览器上点击一个链接时，会产生一个 HTTP 请求，用于获取新的页面内容，而在该请求的报头中，会包含一个 Referrer，用以指定该请求是从哪个页面跳转页来的，常被用于分析用户来源等信息。但是也成为了一个不安全的因素，所以就有了 Referrer-Policy，用于过滤 Referrer 报头内容，其可选的项有： no-referrer no-referrer-when-downgrade origin origin-when-cross-origin same-origin strict-origin strict-origin-when-cross-origin unsafe-url 漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 Referrer-Policy，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。	1）修改服务端程序，给 HTTP 响应头加上 Referrer-Policy 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“Referrer-Policy”, “value”) 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“Referrer-Policy: value”) 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “Referrer-Policy”, “value” 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“Referrer-Policy”] = “value” 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“Referrer-Policy”] = “value”； 2）修改负载均衡或反向代理服务器，给 HTTP 响应头加上 Referrer-Policy 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header Referrer-Policy value; 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add Referrer-Policy “value”。
检测到目标X-Permitted-Cross-Domain-Policies响应头缺失	Web 服务器对于 HTTP 请求的响应头中缺少 X-Permitted-Cross-Domain-Policies，这将导致浏览器提供的安全特性失效。当一些在线的 Web Flash 需要加载其他域的内容时，很多 Web 会通过设置一个 crossdomain.xml 文件的方式来控制其跨域方式。很有可能有些开发者并没有修改 crossdomain.xml 文件的权限，但是又有和跨域的 Flash 共享数据的需求，这时候可以通过设置 X-Permitted-Cross-Domain-Policies 头的方式来替代 crossdomain.xml 文件，其可选的值有： none master-only by-content-type by-ftp-filename all 漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 X-Permitted-Cross-Domain-Policies，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。	1）修改服务端程序，给 HTTP 响应头加上 X-Permitted-Cross-Domain-Policies 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“X-Permitted-Cross-Domain-Policies”, “value”) 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“X-Permitted-Cross-Domain-Policies: value”) 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “X-Permitted-Cross-Domain-Policies”, “value” 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“X-Permitted-Cross-Domain-Policies”] = “value” 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“X-Permitted-Cross-Domain-Policies”] = “value”； 2）修改负载均衡或反向代理服务器，给 HTTP 响应头加上 X-Permitted-Cross-Domain-Policies 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header X-Permitted-Cross-Domain-Policies value; 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add X-Permitted-Cross-Domain-Policies “value”。
检测到目标X-Download-Options响应头缺失	Web 服务器对于 HTTP 请求的响应头中缺少 X-Download-Options，这将导致浏览器提供的安全特性失效。漏洞危害: Web 服务器对于 HTTP 请求的响应头中缺少 X-Download-Options，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。	1）修改服务端程序，给 HTTP 响应头加上 X-Download-Options 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“X-Download-Options”, “value”) 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“X-Download-Options: value”) 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “X-Download-Options”, “value” 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“X-Download-Options”] = “value” 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“X-Download-Options”] = “value”； 2）修改负载均衡或反向代理服务器，给 HTTP 响应头加上 X-Download-Options 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header X-Download-Options value; 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add X-Download-Options “value”。
检测到目标Strict-Transport-Security响应头缺失	Web 服务器对于 HTTP 请求的响应头中缺少 Strict-Transport-Security，这将导致浏览器提供的安全特性失效。当 Web 服务器的 HTTP 头中包含 Strict-Transport-Security 头时，浏览器将持续使用 HTTPS 来访问 Web 站点，可以用来对抗协议降级攻击和 Cookie 劫持攻击。其可选的值有： max-age=SECONDS，表示本次命令在未来的生效时间 includeSubDomains，可以用来指定是否对子域名生效漏洞危害： Web 服务器对于 HTTP 请求的响应头中缺少 Strict-Transport-Security，这将导致浏览器提供的安全特性失效，更容易遭受 Web 前端黑客攻击的影响。	1）修改服务端程序，给 HTTP 响应头加上 Strict-Transport-Security 如果是 java 服务端，可以使用如下方式添加 HTTP 响应头 response.setHeader(“Strict-Transport-Security”, “value”) 如果是 php 服务端，可以使用如下方式添加 HTTP 响应头 header(“Strict-Transport-Security: value”) 如果是 asp 服务端，可以使用如下方式添加 HTTP 响应头 Response.AddHeader “Strict-Transport-Security”, “value” 如果是 python django 服务端，可以使用如下方式添加 HTTP 响应头 response = HttpResponse() response[“Strict-Transport-Security”] = “value” 如果是 python flask 服务端，可以使用如下方式添加 HTTP 响应头 response = make_response() response.headers[“Strict-Transport-Security”] = “value”； 2）修改负载均衡或反向代理服务器，给 HTTP 响应头加上 Strict-Transport-Security 如果使用 Nginx、Tengine、Openresty 等作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： add_header Strict-Transport-Security value; 如果使用 Apache 作为代理服务器，在配置文件中写入如下内容即可添加 HTTP 响应头： Header add Strict-Transport-Security “value”。
点击劫持：X-Frame-Options未配置【可验证】	点击劫持（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-FROM uri：只能被嵌入到指定域名的框架中。例如： apache可配置http.conf如下： “<IfModule headers_module> Header always append X-Frame-Options “DENY” IIS可配置相关网站的Web.config如下： <system.webServer> … … </system.webServer>”	根据点击劫持：X-Frame-Options未配置漏洞原理，通过从目标站点响应头信息中检查X-Frame-Options配置情况进行漏洞验证。
检测到目标网站存在上传下载相关的目录和文件【可验证】	检测到目标网站存在上传下载相关的目录和文件。上传目录一般具有可写权限。攻击者可以预测文件上传的路径，便于和目标站点的其他漏洞攻击结合攻击目标服务器。	检查此类目录的访问权限。如果不需要这些目录，建议删除。	根据检测到目标网站存在上传下载相关的目录和文件漏洞原理，通过访问目标站点上传下载相关的目录和文件并根据响应情况进行漏洞验证。
jQuery 存在 XSS 漏洞【可验证】	jQuery 是一个 JavaScript 库。 jQuery 在过滤用户输入数据时，所使用的正则表达式存在缺陷，可能导致 location.hash 跨站漏洞。	临时解决方案： 1、为应用系统制定允许用户输入字符的白名单，发现输入中存在非白名单中的字符时直接返回固定的错误页面。参考链接： https://bugs.jquery.com/ticket/9521	根据jQuery 存在 XSS 漏洞原理，通过检测jQuery的内容进行漏洞验证。
检测到目标URL存在内部IP地址泄露【可验证】	内部 IP 定义为下列 IP 范围内的 IP： 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 对攻击者而言，泄露内部 IP 非常有价值，因为它显示了内部网络的 IP 地址方案。知道内部网络的 IP 地址方案，可以辅助攻击者策划出对内部网络进一步的攻击。	内部 IP 通常显现在 Web 应用程序/服务器所生成的错误消息中，或显现在 HTML/JavaScript 注释中。 [1] 关闭 Web 应用程序/服务器中有问题的详细错误消息。 [2] 确保已安装相关的补丁。 [3] 确保内部 IP 信息未留在 HTML/JavaScript 注释中。	根据检测到目标URL存在内部IP地址泄露漏洞原理，通过从目标站点获取内部IP地址进行漏洞验证。