为什么浏览器要使用同源策略阻止跨域请求?

最新推荐文章于 2024-09-14 19:44:09 发布

纸醉金迷的程序员

最新推荐文章于 2024-09-14 19:44:09 发布

阅读量696

点赞数 12

分类专栏：计算机网络 Java Web 文章标签：网络安全 java tomcat java-ee

本文链接：https://blog.csdn.net/weixin_44199502/article/details/141027818

版权

Java Web 同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

计算机网络

2 篇文章 0 订阅

订阅专栏

何为同源策略?

何为同源和跨域请求

协议, 地址, 端口三者相同即为同源！有一个不相同，则为不同源！

例如：http://192.168.1.20:8080 和 http://192.168.1.20:8081 就不同源 (端口不一样)。

如果从http://192.168.1.20:8080服务器支持的HTML页面，通过浏览器向http://192.168.1.20:8081的后台服务器发送请求，此请求被称为跨域请求。跨域请求可以被后台服务器处理并返回响应，但响应被浏览器拦截，无法被DOM/JavaScript接收到。验证此情况可以通过浏览器检查，查看请求的响应结果。然而，如果http://192.168.1.20:8080通过Java等原生语言封装一个HTTP请求直接发送给后台服务器，尽管也属于跨域，但响应不会被浏览器的同源策略拦截, 因为压根没有浏览器的存在。

为什么浏览器会使用同源策略拦截跨域请求请求回来的响应?

关于浏览器为什么要使用同源策略拦截跨域请求, chat-gpt 是这样解释的:

浏览器之所以使用同源策略（Same-Origin Policy）来阻止跨域响应，主要是为了保护用户数据安全和隐私。同源策略限制了一个源（域名、协议、端口）的文档或脚本如何能与来自不同源的资源进行交互。这种策略的主要目的是防止恶意网站通过脚本等手段获取用户的敏感信息，或者对其他网站发起恶意请求。

可能不太容易理解，但我们将通过程序进行演示，如果没有同源策略的限制，会面临什么后果。
首先，要明白，浏览器的主要用户群体是谁？大多数是普通用户，而不是了解编程和网络的专业人士。因此，专业人士不会随意访问未知的网站或点击不明链接。请记住，千万不要随意访问不熟悉的网站!

他们, 居然知道我的隐私:

场景描述:

在这个场景中，有三个角色：
① 一个专门用于写日记的网站后台服务器，运行在 http://localhost:8081 上；

② 日记网站的前台服务器，包含多个页面如login.html/index.html等，运行在 http://localhost:9090 端口上；

③ 一个恶意网站，运行在 http://localhost:8080 端口上。该网站知道如何请求日记后台接口，但由于权限不足，无法获取其所需的数据。

故事描述

有一天，小林登陆他最喜欢的日记网站，写了一篇相当“私密”的日记，然后毫不犹豫地点了保存按钮。写完日记后，小林逛了些"有趣"的网站。

第二天，他去了学校，发现整个校园都在传播他的日记内容。小林一头雾水，不明白为什么自己的日记会流出来。于是，他赶紧给日记网站的运营商打电话。

运营商告诉他，网站遭到黑客攻击，导致了这一切不幸的后果，并表示愿意进行赔偿。事情到此算是解决了，但小林不得不考虑转学了。

日记网站为什么会被黑客轻松攻击的内幕:

小张是公司新来的程序员, 他接到项目组给他分配的任务 -> 能够让日记服务器的响应信息通过浏览器的拦截; 他是这样解决的:

@WebFilter("/*")
public class CORSFilter extends HttpFilter {
    @Override
    protected void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
        System.out.println("跨域设置...");
        String originStr = req.getHeader("Origin");
        System.out.println("originStr: " + originStr);
        //解决跨域问题
        res.setHeader("Access-Control-Allow-Origin", originStr);
        res.setHeader("Access-Control-Allow-Methods", "POST, GET, PUT, OPTIONS, DELETE");
        res.setHeader("Access-Control-Max-Age", "3600");
        res.setHeader("Access-Control-Allow-Headers", "x-requested-with, Content-Type");
        res.setHeader("Access-Control-Allow-Credentials", "true");
        chain.doFilter(req, res);
    }
}

不知道小张是从哪个网站抄来的代码，直接粘贴了上去。后来他让前端开发人员访问后端服务器进行测试，结果一切都顺利，信息正确返回。登陆后，也能够访问需要登录权限才能获取的资源。小张因此欢欢喜喜地下班了。

然而，项目上线不到一个月，却碰到了数据泄露的问题。项目组长一看小张负责的代码，毫不犹豫就把他炒了。从此，小张失业了，这可真是一波三折的程序员生涯啊！

小陈的特殊手段:

小陈虽然技术不怎么样，却喜欢折腾一些损人不利己的事情。有一天，他偶然访问了一个日记网站，突然想起了昨天学的Cookie窃取攻击，就决定在这个网站上试试手。他注册了一个账号，并发布了一篇日记。查看已发布日记时，他注意到请求的是后台的getAllDiary资源。

小陈发现每次请求都会带上登录后返回的Cookie，除了一些无关紧要的资源可以不带Cookie访问外，其他涉及敏感信息的都需要携带Cookie才能返回。

他开始思考如何能获取别人登录后的Cookie，除了直接去人家电脑上查看，似乎没有更好的办法。突然，小陈灵机一动，决定搞一个恶意网站。这个网站有个名为“未满18岁禁止点击”的按钮，一旦点击，就会向日记网站后台发送一个带有存储在浏览器中的日记网站Cookie的getAllDiary请求。

这样一来，只要有大冤种访问了日记网站，其浏览器中必然存有这个Cookie。如果还访问了小陈的恶意网站, 恶意网站收到日记网站后台的响应后，通过JavaScript脚本将结果发送到小陈的邮箱。

小林的受害过程

在这里插入图片描述

小张的罪过

在这里插入图片描述
小张因为几行代码丢了工作。其中的"Access-Control-Allow-Origin"是用来指定哪些远程请求的响应可以绕过浏览器的同源策略限制。如果设置为允许任何来源的响应通过跨域响应拦截，就会存在安全风险。比如，小林访问了小陈的恶意网站后，利用之前窃取的登录凭据和Cookie信息发送请求到日记后台服务器。由于服务器鉴权通过且浏览器根据响应头中的Access-Control-Allow-Origin允许跨域访问，恶意页面就成功获取了小林的日记内容。