技术干货之Nginx常见漏洞处理

admin 2023年4月26日00:47:47评论74 views字数 5946阅读19分49秒阅读模式

技术干货之Nginx常见漏洞处理

网安教育

培养网络安全人才

技术交流、学习咨询




01





检测到目标URL存在http host头攻击漏洞

中危


描述:

为了方便的获得网站域名,开发人员一般依赖于HTTP Host header。例如,在php里用_SERVER["HTTP_HOST"]。但是这个header是不可信赖的,如果应用程序没有对host header值进行处理,就有可能造成恶意代码的传入。


检测:

通过burp进行抓包:

技术干货之Nginx常见漏洞处理

技术干货之Nginx常见漏洞处理

技术干货之Nginx常见漏洞处理

这就说明,可以随意更改报头的Host,请求都可以被执行,返回200,这就有可能被利用,构造恶意的代码传入并执行。


处理:

在Nginx里还可以通过指定一个SERVER_NAME名单,Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项

1server_name  XXX.XXX.com xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx;
2if ( $host !~* 'XXX.XXX.com|xxx.xxx.xxx.xxx|xxx.xxx.xxx.xxx' )
3 {
4return 403;
5 }


技术干货之Nginx常见漏洞处理

技术干货之Nginx常见漏洞处理

参考:

https://www.cnblogs.com/xidxi/p/14781383.html

https://www.cnblogs.com/huiy/p/13433643.html



02





点击劫持:X-Frame-Options未配置



描述:

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


检测:

访问页面,F12查看响应头

没有配置X-Frame-Options响应头


处理:

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

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

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

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

(另外两种配置方式e.g.):

1# add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com; 
2# add_header X-Frame-Options:DENY;


这里一般选择SAMEORIGIN配置,只允许本站页面被嵌入到iframe。

在nginx的server里面配置:

1add_header X-Frame-Options "SAMEORIGIN";

再查看页面响应头X-Frame-Options,实现漏洞规避。


参考:

https://www.zhihu.com/question/31785438

https://www.cnblogs.com/xidxi/p/14781383.html



03





检测到目标X-Content-Type-Options响应头缺失



描述:

响应头用来指定浏览器对未指定或错误指定Content-Type资源真正类型的猜测行为,nosniff 表示不允许任何猜测,在通常的请求响应中,浏览器会根据Content-Type来分辨响应的类型,但当响应类型未指定或错误指定时,浏览会尝试启用MIME-sniffing来猜测资源的响应类型,这是非常危险的,例如一个.jpg的图片文件被恶意嵌入了可执行的js代码,在开启资源类型猜测的情况下,浏览器将执行嵌入的js代码,可能会有意想不到的后果。


检测:

访问页面,F12查看响应头

没有配置X-Content-Type-Options响应头


处理:

1# add_header X-Content-Type-Options: nosniff; 


如果服务器发送响应头 “X-Content-Type-Options: nosniff”,则 script 和 styleSheet # 元素会拒绝包含错误的 MIME 类型的响应。这是一种安全功能,有助于防止基于 MIME 类型混淆的攻击。

在nginx的server里面配置:

1add_header X-Content-Type-Options "nosniff";


技术干货之Nginx常见漏洞处理


参考:

https://blog.csdn.net/weixin_41986096/article/details/108319848



04





检测到目标X-XSS-Protection响应头缺失



描述:

HTTP X-XSS-Protection 响应头是 Internet Explorer,Chrome 和 Safari 的一个特性,当检测到跨站脚本攻击 (XSS)时,浏览器将停止加载页面。X-XSS-Protection响应头的缺失使得目标URL更易遭受跨站脚本攻击。


检测:

访问页面,F12查看响应头

没有配置X-XSS-Protection响应头


处理:

1# 0:# 禁用XSS保护; 
2# 1:# 启用XSS保护; 
3# 1; # mode=block:启用XSS保护,并在检查到XSS攻击时,停止渲染页面(例如IE8中,检查到攻击时,整个页面会被一个#替换); 
4# 浏览器提供的XSS保护机制并不完美,但是开启后仍然可以提升攻击难度,总之没有特别的理由,不要关闭它。


在nginx的server里面配置:

1add_header X-XSS-Protection "1; mode=block";


表示若检查到XSS攻击则停止渲染页面

技术干货之Nginx常见漏洞处理


参考:

https://www.cnblogs.com/xidxi/p/14781383.html



05





检测到目标Content-Security-Policy响应头缺失


描述:

内容安全策略(Content Security Policy)是一种声明的安全机制,可以让网站运营者能够控制遵循CSP的用户代理(通常是浏览器)的行为。通过控制要启用哪些功能,以及从哪里下载内容,可以减少网站的攻击面。

CSP的主要目的是防御跨站点脚本(cross-ste scripting,XSS)攻击。例如,CSP可以完全禁止内联的JavaScript,并且控制外部代码从哪里加载。它也可以禁止动态代码执行。禁用了所有的攻击源,XSS攻击变得更加困难。

CSP由Mozilla开发,曾经有几年试验过概念,一开始称为内容限制(content restriction),后来改称为内容安全策略。2012年11月CSP 1.0成为W3C的候选议案。

网站通过设置Content-Security-Policy响应头启用所需的CSP策略。


检测:

访问页面,F12查看响应头有没有配置Content-Security-Policy响应头


处理:

1#并不限制内容加载来源                                                                                    
2add_header Content-Security-Policy "script-src * 'unsafe-inline' 'unsafe-eval'";                                                                                         
3#将本站内部http链接自动改为https,并不限制内容加载来源                                                                                    
4#add_header Content-Security-Policy "upgrade-insecure-requests;content *;img-src '*'";
5upgrade-insecure-requests CSP 指令的作用就是让浏览器自动升级请求,防止访问者访问不安全的内容。


该指令用于让浏览器自动升级请求从http到https,用于大量包含http资源的http网页直接升级到https而不会报错.简洁的来讲,就相当于在http和https之间起的一个过渡作用.

nginx的server里面配置:

1add_header Content-Security-Policy "script-src * 'unsafe-inline' 'unsafe-eval'";


技术干货之Nginx常见漏洞处理


参考:

http://www.hlcjw.cn/archives/533

https://www.jianshu.com/p/62d7053d1e5d

https://blog.csdn.net/unhejing/article/details/107606615



06





检测到目标Referrer-Policy响应头缺失



描述:

在页面调用图片等其它资源时,或者发生页面跳转时,都会向服务端发生一个带Referrer的HTTP请求,这也是一些网站做防盗链的抓手,在Referrer Policy策略发面前,浏览器可以按自己的默认规则来决定是否加上Referrer。2014年W3C下Web应用安全工作组(Web Application Security Working Group)发布了Referrer Policy草案,对浏览器发送Referrer做了详细规定。在新的Referrer Policy中,可以实现隐藏Referrer,也可以只发送来源URL的host地址(不过不允许伪造)。


检测:

访问页面,查看响应头


处理:

no-referrer 全省略

no-referrer-when-downgrade 协议的安全级别降低时全省略,即HTTPS -> HTTP

strict-origin 协议的安全级别相等时仅发送源,不等时全省略

origin 仅发送源

same-origin 同源时全发送,跨源时全省略

strict-origin-when-cross-origin 同源时全发送,跨源时协议的安全级别相等时仅发送源,不等时全省略

origin-when-cross-origin 同源时全发送,跨源时只发送源

unsafe-url 全发送

在nginx的server里面配置:

1add_header 'Referrer-Policy' 'origin';


技术干货之Nginx常见漏洞处理

Ps:该配置导致finderweb打不开,修改配置如下:

1add_header 'Referrer-Policy' 'strict-origin-when-cross-origin';

即可


参考:

http://www.04007.cn/article/778.html

https://jsweibo.github.io/2020/05/06/HTTP中的Referrer-Policy响应头/

https://blog.csdn.net/wwppp987/article/details/117822609



07





检测到目标X-Download-Options响应头缺失



处理:

1add_header X-Download-Options "noopen" always;


参考:

https://blog.csdn.net/wwppp987/article/details/117822609



08





检测到目标X-Permitted-Cross-Domain-Policies响应头缺失洞



描述:

用于指定当不能将"crossdomain.xml"文件(当需要从别的域名中的某个文件中读取 Flash 内容时用于进行必要设置的策略文件)放置在网站根目录等场合时采取的替代策略。

master-only 只允许使用主策略文件(/crossdomain.xml)


处理:

1add_header X-Permitted-Cross-Domain-Policies  "master-only";


参考:

https://blog.csdn.net/wwppp987/article/details/117822609

https://www.cnblogs.com/oneapm/p/5168793.html



09





检测到目标Strict-Transport-Security响应头缺失



描述:

用于通知浏览器只能使用 HTTPS 协议访问网站。用于将 HTTP 网站重定向到 HTTPS 网站。


处理:

Strict-Transport-Security: max-age=31536; includeSubDomains

max-age 用于修改 STS 的默认有效时间。

includeSubDomains 用于指定所有子域名同样使用该策略。

preload,可选参数,一个浏览器内置的使用HTTPS的域名列表。

在nginx上配置:

1add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";


参考:

https://blog.csdn.net/u012560410/article/details/86489979

https://blog.csdn.net/weixin_42715225/article/details/108520181

https://blog.csdn.net/wwppp987/article/details/117822609



10





HTTP动词篡改的认证旁路



检测:

技术干货之Nginx常见漏洞处理


处理:

1     if ($request_method !~ ^(GET|HEAD|POST)$ )
2   { 
3     return 501;
4   }


技术干货之Nginx常见漏洞处理


参考:

https://idc.wanyunshuju.com/ngi/1059.html


END
技术干货之Nginx常见漏洞处理


文:Hai

原文链接:https://www.cnblogs.com/haiyoyo/p/17093874.html

版权声明:著作权归作者所有。如有侵权请联系删除


网安训练营

网络安全基础班、实战班线上全面开启,学网络安全技术、升职加薪……有兴趣的可以加入网安大家庭,一起学习、一起成长,考证书求职加分、升级加薪,有兴趣的可以咨询客服小姐姐哦!

技术干货之Nginx常见漏洞处理

加QQ(1005989737)找小姐姐私聊哦



精选文章


环境搭建
Python
学员专辑
信息收集
CNVD
安全求职
渗透实战
CVE
高薪揭秘
渗透测试工具
网络安全行业
神秘大礼包
基础教程
我们贴心备至
用户答疑
 QQ在线客服
加入社群
QQ+微信等着你

技术干货之Nginx常见漏洞处理


我就知道你“在看”
技术干货之Nginx常见漏洞处理


原文始发于微信公众号(开源聚合网络空间安全研究院):技术干货之Nginx常见漏洞处理

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年4月26日00:47:47
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   技术干货之Nginx常见漏洞处理http://cn-sec.com/archives/1689450.html

发表评论

匿名网友 填写信息