防御XSS攻击

原则：不要相信用户传递的数据

1. 转义输出：避免直接将用户传递的数据作为DOM呈现，即在将用户数据呈现到HTML页面前，进行转义处理，防止浏览器将数据解释为脚本代码；

2. 验证&过滤：对用户输入、传递的数据进行验证和过滤，包括上传的图片、自定义css样式、表单等；

3. 限制用户权限：限制用户只能访问其需要的功能和数据；

4. 避免内联脚本：将JS代码放在外部文件中引用；

5. 设置HTTP信息：

   • 响应头设置Content Security Policy（白名单制度）​限制浏览器执行的脚本来源

   • 设置Cookie时，标记其为HTTPOnly​，防止JS脚本访问cookie

     使用Secure​标志确保Cookie只在加密的安全连接中传输

6. 使用安全的开发框架和库：

   一般主流的框架默认防御XSS

防御CSRF

CSRF：恶意网站/异常来源设法伪造带有正确Cookie的HTTP请求。

1. 限制Origin

   检验请求头中的Origin​或者Referer​判断请求是否来源于同源请求或正常请求，从而过滤异常请求。

2. 针对Iframe的防御：

   由于Iframe通过页面嵌套的方式将两个非同源的页面嵌套在一起，绕过了同源策略实现跨域请求，对于这种方式需要针对性的防御策略。

   添加HTTP响应头X-Frame-Options​：

   • ​DENY​：限制该页面不能作为Iframe加载；
   • ​SAMEORIGIN​：只有同源的页面才能作为Iframe加载。

3. Same-Site Cookie

   Cookie新增属性SameSite​用于限制第三方Cookie：

   • ​Strict​

     完全禁止第三方Cookie，即只有同域名下的请求才能带上本页面的Cookie，限制非同域名的请求携带本页面的Cookie：

     Set-Cookie: SameSite=Stric;
     

   • ​Lax​

     默认值，大多数情况下不发送Cookie，但是导航到目标网址的GET请求除外（只包括三种情况：链接、预加载请求、GET表单）:

     Set-Cookie: SameSite=Lax;
     

   • ​None​

     关闭该属性，但是必须同时设置Secure​属性，否则无效，仍会被视为默认值Lax​。通常是不得不将Cookie转发给第三方网站的场景下使用：

     Set-Cookie: SameSite=None; Secure;
     

防御注入攻击

1. 最小权限原则：不给予请求root​权限
2. 建立白名单：只允许指定请求执行，过滤有嫌疑的请求
3. 限制URL参数类型：限制URL类型参数中的协议、域名、ip等，禁止访问内网

防御Dos攻击

1. 针对基于正则表达式的Dos攻击

   利用正则表达式的复杂度或漏洞，将目标系统的资源耗尽，使之性能下降，从而无法提供正常的服务。例如，表单输入需要匹配一个只含字母和数字的正则，而攻击者发送一个非常长的字符串，其中包含大量字母和数字的重复序列，在正则表达式处理时需要耗费大量时间和计算资源来匹配这个超长字符串，最终导致系统无法正常运行。

   • 开发过程中避免使用贪婪匹配的正则
   • 使用代码扫描工具，扫描代码中的正则并进行性能测试
   • 拒绝使用用户提供的正则表达式

2. 针对DDos攻击

   • 流量治理

     • 负载均衡：将网络流量合理分发到多个服务器或网络设备中，缓解DDos攻击对目标系统的压力；
     • API网关：在应用程序和外部请求之间设置中间人，称为网关，对进入应用程序的流量进行控制、阻止恶意请求等；
     • CDN：同样是将资源分散到多台服务器中，降低单台目标系统收DDos攻击的影响。

   • 自动快速扩容：配置资源自动扩展机制，受攻击系统能够快速扩展资源和容量，以应对巨大流量和负载压力；

   • 非核心服务降级：受攻击系统中的一些非关键服务或功能暂时降级或关闭，以便为核心服务保留更多资源和带宽。

‍