不必要的http头
修改nginx.conf以及需要加载新的模块
请参考链接提示进行配置:https://blog.csdn.net/zzhongcy/article/details/115538272
检测到隐藏目录
1、需要新增一个404.html 不存在的页面。Html内容写404就行
2、修改nginx.conf的 error_page 下修改
error_page 404 403 500 502 503 504 /404.html;
# 承接上面的location。
location = /404.html {
# 放错误页面的目录路径。
root /usr/local/nginx112/html/;
}
“X-Content-Type-Options”头缺失或不安全
修改nginx.conf的 server 下添加
add_header X-Xss-Protection "1;mode=block";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
具有不安全、不正确或缺少 SameSite 属性的 Cookie
修改nginx.conf的server下面location配置
location ^/abc/ {
proxy_cookie_path / "/; secure; SameSite=Strict;HttpOnly;SameSite=Strict";
}
启用了不安全的“OPTIONS”HTTP 方法
修改应用程序配置文件
如tomcat一般位web.xml,配置后重启服务
改为:
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint></auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
各项配置说明:
<security-constraint>用于限制对资源的访问;
<auth-constraint>用于限制那些角色可以访问资源,这里设置为空就是禁止所有角色用户访问;
<url-pattern>指定需要验证的资源
<http-method>指定那些方法需要验证
主机头注入攻击
1、服务器修复方案
唯一可信的只有 SERVER_NAME,这个在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。
Nginx里还可以通过指定一个SERVER_NAME名单,Apache也可以通过指定一 个SERVER_NAME名单并开启UseCanonicalName选项。
建议以上两种方法同时使用。
1.1Nginx修复方法
方案1:修改nginx.conf,添加一个默认server,当host头被修改匹配不到server时会跳到该默认server,该默认server直接返回403错误。配置完成后重启nginx即可。
server {
listen 8888 default;
server_name 192.168.0.171;
location / {
return 403;
}
}
方案2:修改nginx.conf,在目标server添加检测规则,参考以下配置,配置完成后重启nginx即可。
server {
server_name 192.168.0.171;
listen 8888;
if ($http_Host !~*^192.168.0.171:8888$)
{
return 403;
}
include /etc/nginx/default.d/*.conf;
location / {
root /www/dvwa;
index index.php index.html index.htm;
}
}
1.2Apache修复方法
方案1:修改\conf\httpd.conf文件,修改ServerName为应用的域名,并开启UseCanonicalName选项配置完成后重启Apache即可:
ServerName 10.1.25.233:80
UseCanonicalName On
方案2:修改\conf\httpd.conf文件,参考以下配置添加,配置完成后重启Apache即可。配置说明:拒绝直接通过192.168.0.16这个IP的任何访问请求,这时如果你用192.168.0.16访问,会提示拒绝访问。仅允许通过www.test.com这个域名访问,主目录指向C:\www
NameVirtualHost 192.168.0.16
<VirtualHost 192.168.0.16>
ServerName 192.168.0.16
<Location />
Order Allow,Deny
Deny from all
</Location>
</VirtualHost>
<VirtualHost 192.168.0.16>
DocumentRoot "C:\www"
ServerName www.test.com
</VirtualHost>
方案3:修改\conf\httpd.conf文件,找到”#LoadModule rewrite_module modules/mod_rewrite.so”去除前面的”#”号,添加类似以下配置,配置完成后重启Apache即可。配置说明:当HOST头不是192.168.0.16时,重定向到错误页面
RewriteEngine on
RewriteCond %{HTTP_HOST} !^192.168.0.16$ [NC]
RewriteRule ^(.*)$ /error.html
1.3Tomcat修复方法
方案1:修改tomcat\conf\server.xml,找到以下将Host里的name修改为静态的域名,配置完成后重启Apache即可。
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
方案2:修改tomcat\conf\server.xml,将Host节点做如下配置:
<Host name="www.baidu.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false"><!--本机对外域名-->
<Alias>10.1.8.1</Alias>
<Alias>10.1.8.2</Alias><!--本机所支持的所有IP-->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt" resolveHosts="false"
pattern="%a %A %b %B %h %H %l %m %p %s %S %t %u %U %v %D %T" />
</Host>
1.4IIS6.0修复方法:使用ISAPI_Rewrite插件对请求包内容进行检测并重写URL
1.5IIS7.0/7.5/8.0修复方法:微软推出了一款URL 重写模块工具,可对请求URL进行过滤处理
2、应用方面
在网站安装和初始化的时候,要求管理员提供一个可信任的域名白名单。如果这个实现起来比较困难,那至少也要保证使用使用getServerName()代替getHeader(“Host”)。
Spring Boot Actuator 端点
1、禁用所有端点,修改配置文件application.yml为以下配置:
management:
endpoints.enabled = false
2、若系统必须启用端点的建议配置认证,在项目的pom.xml文件下引入spring-boot-starter-security依赖:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
然后在application.properties中开启security功能,配置访问账号密码(示例仅供参考),重启应用即可弹出。
management.security.enabled=true
security.user.name=adminmmmm
security.user.password=F!a16a<<ss%%$s9
3、升级Spring Boot的版本,由于Spring Boot < 1.5 默认未授权访问所有端点,在Spring Boot >= 1.5 默认只允许访问/health和/info端点,建议升级到SpringBootActuator2.0以上。
4、禁止互联网访问端点。
CORS 策略
避免在内部网络中使用通配符,如果Web资源包含敏感信息,则应在Access-Control-Allow-Origin标头中正确指定来源,指定的来源只能是受信任的站点,同时避免将null列入白名单。如果不需要外部访问,请完全除去此头。
可以通过修改配置文件application.yml如下,allowed-origins中允许跨域的ip地址;allowed-methods配置允许通过的请求,还有支持时间等;
management:
endpoints:
web:
# 跨域处理
cors:
allowed-origins: http://localhost:8080/
allowed-methods: post,get,put
临时文件下载、归档文件下载、压缩文件
这几类一般是处理错误信息时,响应不规范造成。
自定义错误页面或使用统一的错误页面提示。
1、对于 tomcat 的中间件下,常用修复方式如下:找到配置文件 web.xml ,修改内容,配置一个统一的静态页面,将400、403、404、500等常见报错重定向到该静态页面,而不是抛出异常(报错信息导致代码信息泄漏);
2、对于常用的jsp语言开发的网站,可在业务流程中,加入异常捕获过程中预定义的错误编码,将异常输出到错误日志中,并在前台页面返回相应的错误编码,以便应用系统运维人员进行异常排查。
3、对于 IIS/ASP.net 下设置404错误页面:修改应用程序根目录的设置,打开 “web.config” 文件编辑,加入错误提示页面及提示内容。
4、对于 apache 服务器的设置:修改 httpd.conf 文件,去掉错误提示页面的注释符“#”。
5、对于 PHP 中间件的使用者,可通过修改 php.ini 文件来实现如果关闭与开启错误信息,关闭错误显示后,php函数执行错误的信息将不会再显示给用户,这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置,以及一些其它有用的信息,起码给攻击者的黑箱检测造成一定的障碍。
6、对于 J2EE 项目开发的网站,如果想通过捕获抛出的异常信息的方式来修复,可以使用使用 Spring MVC 统一异常处理的方法来进行修复。
7、编码时增加异常处理模块,对错误页面做统一的自定义返回界面,隐藏服务器版本信息;
8、不对外输出程序运行时产生的异常错误信息详情。
————————————————
版权声明:本文为CSDN博主「月慕向阳」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_41796956/article/details/132289862