跨域

当浏览器执行脚本时会检查是否同源，只有同源的脚本才会执行，如果不同源即为跨域。

• 这里的同源指访问的协议、域名、端口都相同。
• 同源策略是由 Netscape 提出的著名安全策略，是浏览器最核心、基本的安全功能，它限制了一个源中加载脚本与来自其他源中资源的交互方式。
• Ajax 发起的跨域 HTTP 请求，结果被浏览器拦截，同时 Ajax 请求不能携带与本网站不同源的 Cookie。
• script、img、iframe、link、video、audio 等带有 src 属性的标签可以从不同的域加载和执行资源。

如当使用 ajax 提交非同源的请求时，浏览器就会阻止请求。提示
Access to XMLHttpRequest at ‘...‘ from origin ‘...‘ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin‘ header is present on the requested resource.

如何实现跨域请求呢？

1、jsonp
利用了 script 不受同源策略的限制
缺点：只能 get 方式，易受到 XSS攻击

2、CORS（Cross-Origin Resource Sharing）,跨域资源共享
当使用XMLHttpRequest发送请求时，如果浏览器发现违反了同源策略就会自动加上一个请求头 origin；
后端在接受到请求后确定响应后会在后端在接受到请求后确定响应后会在 Response Headers 中加入一个属性 Access-Control-Allow-Origin；
浏览器判断响应中的 Access-Control-Allow-Origin 值是否和当前的地址相同，匹配成功后才继续响应处理，否则报错
缺点：忽略 cookie，浏览器版本有一定要求

3、代理跨域请求
前端向发送请求，经过代理，请求需要的服务器资源
缺点：需要额外的代理服务器

4、Html5 postMessage 方法
允许来自不同源的脚本采用异步方式进行有限的通信，可以实现跨文本、多窗口、跨域消息传递
缺点：浏览器版本要求，部分浏览器要配置放开跨域限制

5、修改 document.domain 跨子域
相同主域名下的不同子域名资源，设置 document.domain 为 相同的一级域名
缺点：同一一级域名；相同协议；相同端口

6、基于 Html5 websocket 协议
websocket 是 Html5 一种新的协议，基于该协议可以做到浏览器与服务器全双工通信，允许跨域请求
缺点：浏览器一定版本要求，服务器需要支持 websocket 协议

7、document.xxx + iframe
通过 iframe 是浏览器非同源标签，加载内容中转，传到当前页面的属性中
缺点：页面的属性值有大小限制

XSS跨站脚本攻击

XSS （Cross-Site Scripting）跨站脚本攻击是一种常见的安全漏洞，恶意攻击者在用户提交的数据中加入一些代码，将代码嵌入到了Web页面中，从而可以盗取用户资料，控制用户行为或者破坏页面结构和样式等。为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。

最简单的就是当我们提交一个查询后弹出一个alert页面，却无论如何都关不掉，这就是发生了XSS跨站脚本攻击。

XSS产生原因：

XSS产生的原因是过于信任客户端的数据，没有做好过滤或者转义等工作。如果客户端上传的数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，这样就造成了XSS攻击。

XSS分类：

• 存储型：攻击者将恶意代码存储到了数据库中，在响应浏览器请求的时候返回恶意代码，并且执行。这种攻击常见于带有用户保存数据的网站功能；
• 反射型：将恶意代码放在URL中，将参数提交到服务器。服务器解析后响应，在响应结果中存在XSS代码，最终通过浏览器解析执行；
• DOM型：取出和执行恶意代码由浏览器端完成，属于前端 JavaScript的安全漏洞。

XSS防御：

• 对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie；
• 对输入内容的特定字符进行编码，前端后端都可以对传入的内容进行过滤，去掉带javascript等字段的输入

CSRF跨站请求伪造

CSRF（ Cross-site request forgery）跨站请求伪造，也是一种常见的安全漏洞。XSS相当于是控制了站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。

CSRF举例：

用户登录受信任网站A，并在本地生成登录态Cookie。（如果用户没有登录网站A，那么网站B在获取A网站的信息并且去请求网站A的接口时，会提示登录）在不登出A的情况下，访问恶意网站B，那么网站B得到了网站A的所有信息，然后B网站去请求A网站的接口，伪装成A网站的正常请求为所欲为。

下边以示意图来说明CSRF整个流程：

注意：

CSRF中恶意网站仅仅是伪装成了正常用户，但是其并不可以直接获取到正常用户的登录态cookie等信息。如果不做防御，被攻击网站服务器是无法区分是否是冒用用户，因为当前请求确实带着登录凭证等信息。

CSRF防御：

• Referer 头验证：在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。不靠谱，Referer可以被改变；
• Token验证：服务器发送给客户端一个Token，客户端提交的表单中（或者URL上）带着这个Token。如果这个Token 不合法，那么服务器拒绝这个请求。
• 双重Cookie验证：利用恶意网站无法获取cookie信息，仅可冒用的特点，我们将cookie中的参数取出来，加入到请求参数中，服务端进行校验，如果参数中没有附加额外的cookie中的参数，那么就拒绝请求。

解析：

XSS和CSRF均属于安全漏洞，和我们的开发工作息息相关。对于一些对安全性有一定要求的方向和岗位，了解常见的XSS和CSRF攻击无疑是面试的一大加分项。

那么CSRF和XSS的区别有哪些呢？

• CSRF攻击需要用户先登录网站A，恶意网站B获取到A网站用户的 cookie；
• XSS攻击则不需要登录。
• CSRF攻击本质是利用网站A本身的漏洞，去请求网站A的相关接口；
• XSS攻击向网站 A 注入恶意代码，然后通过执行恶意代码，篡改了网站A的内容。

SSRF服务端请求伪造

SSRF是一种由攻击者构造请求，利用服务端发起的一种安全漏洞。一般情况下，SSRF攻击的目标是外网无法访问的内部系统。

我们先来看下SSRF攻击的示意图：

SSRF漏洞举例：

• 正常的网络请求流程：客户端A发起请求 -> 服务端B接收请求 -> 服务端B处理请求 -> 服务端B返回响应
• 存在SSRF漏洞下的网络请求流程：

比如现在客户端A发起的请求是这样的 www.xxxxx.com/xxx.php?image=www.abc.com/photo.jpg。 服务端B收到该请求后，会接着取访问www.abc.com/photo.jpg 获取资源文件。如果服务端B对客户端发起的请求没有进行过滤等操作，那么?image=可能会被恶意篡改。最后的结果就是，借助于公网上的服务器来访问了内网系统。

SSRF产生原因：

SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤与限制。比如指定URL地址获取网页文本内容，加载指定地址的图片和文档等。

常见SSRF漏洞出现场景：

• 分享场景，通过URL地址分享网页内容。
• 转码服务，在线翻译场景。
• 地址加载或下载图片。
• 图片、文章收藏功能。
• 未公开的api实现以及其他调用URL的功能等。

SSRF漏洞危害：

因为外网借助了服务端来实现了对内网服务器的访问，所以很多操作都可以进行，包括如下的危害：

• 对服务器所在的内网进行端口扫描，获取一些服务的banner信息等。
• 攻击运行在内网或者本地的应用程序。
• 对内网WEB应用进行指纹识别，通过访问默认文件实现。
• 下载内网的一些资源文件等。

SSRF的防御措施：

• 对错误信息进行统一处理，避免用户可以根据错误信息来判断远端服务器的端口状态。
• 对请求的端口进行限制，限定为HTTP常用的端口，比如，80，443和8080等。
• 设定IP黑名单。避免应用被用来获取内网数据，攻击内网。
• 禁用不需要的协议。仅仅允许HTTP和HTTPS请求。
• 对返回信息进行有效过滤等。

SQL注入

SQL注入是指通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器，执行恶意的SQL命令。

SQL注入就是服务端将客户端传入的恶意SQL语句直接进行了执行，这样会导致问题出现。比如说用户在登录的时候，使用了or 1=1来完成身份验证和授权。

SQL注入是一种流行的攻击攻击方法，但是通过一些手段是可以防御该攻击的，常见的防御手段如下：

• 使用预编译语句，比如MyBatis中的SQL语句使用#号代替$符号。
• 使用安全的存储过程来防止SQL注入。
• 对客户端的输入进行数据类型的检查等

java后端知识点梳理——web安全

原文：https://www.cnblogs.com/kylinxxx/p/14021798.html