Web 安全

XSS 攻击

跨站脚本攻击(Cross Site Scripting)，为了不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。

XSS分为:存储型和反射型

存储型XSS:存储型XSS，持久化，代码是存储在服务器中的，如在个人信息或发表文章等地方，加入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易造成蠕虫，盗窃cookie(虽然还有种DOM型XSS，但是也还是包括在存储型XSS内)。

反射型XSS:非持久化，需要欺骗用户自己去点击链接才能触发XSS代码(服务器中没有这样的页面和内容)，一般容易出现在搜索页面。

一句话总结：xss 其实就是 javascript 脚本注入攻击。

XSS漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法，那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为，通常难以看到XSS漏洞的威胁，而该病毒则将其发挥得淋漓尽致。

1)恶意用户，在一些公共区域(例如，建议提交表单或消息公共板的输入表单)输入一些文本，这些文本被其它用户看到，但这些文本不仅仅是他们要输入的文本，同时还包括一些可以在客户端执行的脚本。如:

<script>

this.document = “*********”;

</script>

2)恶意提交这个表单

3)其他用户看到这个包括恶意脚本的页面并执行，获取用户的cookie等敏感信息。

举栗子：

例如在提交表单后，展示到另一个页面，可能会受到XSS脚本注入，读取本地cookie远程发送给黑客服务器端。

<script>alert(‘sss’)</script>

<script>window.location.href=’http://www.baidu.com’;</script>

对应html源代码: <script>alert(‘sss’)</script>

最好使用火狐浏览器演示效果

XSS 攻击使用 JS 脚本语言，因为浏览器默认支持脚本语言执行，如果在表单提交的时候，提交一些脚本参数，可能浏览器直接进行执行。例如：<script>window.location.href=’http://www.baidu.com’;</script>  如果没有做XSS防御，一旦执行 浏览器就会跳转到 百度的网站。在真正的项目中，这种现象是不允许存在的。

XSS漏洞场景：

论坛评论的时候没有做XSS漏洞防御。

解决方案

对一些特殊字符进行转义处理，<script>window.location.href=’http://www.baidu.com’;</script> 对这段脚本中的 <、> 符号进行转义，转化为 &lt、&gt。这样就可以防御XSS 攻击。

在程序中我们只需要在拦截器，拦截所有的请求对请求参数做转义处理即可，将脚本特殊字符，转换成html源代码进行展示。

汉子编码http://www.mytju.com/classcode/tools/encode_gb2312.asp

步骤：编写过滤器拦截所有getParameter参数，重写httpservletwrapp方法

将参数特殊字符转换成html源代码保存.

public static void main(String[] args) {
 String name = "<script>";
 System.out.println("转化前：" + name);
 //对特殊字符串进行转义处理
 System.out.println("转化后：" + StringEscapeUtils.escapeHtml(name));
}

输出结果为：

       转化前：<script>
       转化后：&lt;script&gt;

* xss 原理：
* 1.使用过滤器 拦截所有请求的参数
* 2.重写 getParameter() 方法
* 3.对特殊字符参数进行转义】

Sql 注入

SQL注入：利用现有应用程序，将（恶意）的SQL命令注入到后台数据库执行一些恶意的sql操作。

造成SQL注入的原因是因为程序没有有效过滤用户的输入，使攻击者成功的向服务器提交恶意的SQL查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码

不要使用拼接SQL语句方式、最好使用预编译方式，在mybatis编写sql语句的时候，最好使用?传参数方式，不要使用#传参数，因为#传参数方式，可能会受到sql语句攻击。

如果在程序代码中，sql 语句如果使用拼接的方式，那么可能会出现 Sql 注入的问题。在写程序中，sql 语句中我们应该使用预编译方式，使用 # 符号,而不是使用 $ 符号。

${}: 仅仅为一个纯碎的 string 替换，在动态 SQL 解析阶段将会进行变量替换。

Mybatis 中，sql 语句传递参数的时候，最好使用 #号，因为# 号是预编译的可以有效的防止 Sql 语句注入攻击。$ 号 是使用 Sql 语句拼接，可能会受到 Sql 语句的攻击。 

 举栗子：

@Select(" SELECT * FROM userInfo where userName='${userName}' and password='${password}'")
UserEntity login(UserEntity userEntity);

由上面的访问可知，我访问登录接口没有传密码最后也登陆成功，这显示是不正确的。我们的sql语句应该使用预编译方式，如下。

@Select(" SELECT * FROM userInfo where userName=#{userName} and password=#{password}")
UserEntity login(UserEntity userEntity);

由以上结果可知，使用预编译方式，可以防止 Sql 注入的问题。

Http请求防盗链

比如A网站有一张图片，被B网站直接通过img标签属性引入，直接盗用A网站图片展示。

相当于限制资源(图片、视频、、文件)只能在某个域名(限制某个服务器)来源上进行访问。

判断http请求头Referer域中的记录来源的值，如果和当前访问的域名不一致的情况下，说明该图片可能被其他服务器盗用。Referer 字段中记录了访问的相关信息。

使用 http 协议请求头中的 Referer 记录请求来源与要限制的域名进行比较，如果一致则是限制的域名，如果不一致 说明可能被盗用了。

我在本地 hosts 文件中配置了2个域名做为演示，hosts 文件目录：C:WindowsSystem32driversetc

项目中我允许访问地址是：www.test.com:8080。

地址一致：

地址不一致：

出现以上的效果说明，防盗链功能已经做好了。

注意测试的时候,最好开启两个不同的浏览器测试，避免图片缓存的原因

CSRF攻击

（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一,也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用也就是人们所知道的钓鱼网站。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

一句话总结：CSRF 也就是模拟请求。

互联网公司里面会话信息可能使用的是Token方式进行保存的。

也就是保证数据的唯一性，不允许重复。例如：防止表单重复提交。

怎么样防止重复提交

怎么防止网络延迟情况下的重复提交

多版本并发控制，该策略主要使用 update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中，合理的使用乐观锁，通过 version 或者 updateTime（timestamp）等其他条件，来做乐观锁的判断条件，这样保证更新操作即使在并发的情况下，也不会有太大的问题。例如

  select * from tablename where condition=#condition# // 取出要跟新的对象，带有版本 versoin

  update tableName set name=#name#,version=version+1 where version=#version#

 在更新的过程中利用 version 来防止，其他操作对对象的并发更新，导致更新丢失。为了避免失败，通常需要一定的重试机制。

在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

select for update，整个执行过程中锁定该订单对应的记录。注意：这种在 DB 读大于写的情况下尽量少用。

业务要求：表单只能被提交一次，不能进行重复提交。

发生原因：由于重复点击或者网络重发，或者 nginx 重发等情况会导致数据被重复提交。

解决办法：

集群环境：采用 token 加 redis（redis 单线程的，处理需要排队）

单 JVM 环境：采用 token 加 redis 或 token 加 jvm 内存

处理流程：

数据提交前要向服务的申请 token，token 放到 redis 或 jvm 内存，token 有效时间

提交后后台校验 token，同时删除 token，生成新的 token 返回

token 特点:要申请，一次有效性，可以限流

客户端每次在调用接口的时候,需要在请求头中，传递令牌参数，每次令牌只能用一次。

一旦使用之后，就会被删除，这样可以有效防止重复提交。

步骤:

1.生成令牌接口

2. 接口中获取令牌验证

如何防止机器模拟请求(使用小程序模拟发送请求，例如：使用httpClient 技术)

使用图形验证码防止机器模拟接口请求攻击或者使用Nginx 实现限流、配置黑名单和白名单。

建议：在调用核心业务接口时，比如支付、下单、等接口，最好使用手机短信验证验证或者是人脸识别，防止其他用户使用Token伪造请求。

在互联网公司中，会话信息使用令牌方式保存的。

如何防止黑客使用抓包工具分析到token，然后黑客使用令牌伪造支付、下单等核心操作。

目前市场上没有绝对能够防止黑客不能抓包分析token的技术。

我们可以使用短信验证码方式或者图像识别(人脸识别)的方式来提高安全性。

原文链接：https://www.cnblogs.com/ming-blogs/p/11032234.html