跨域问题的复现与整理

最新推荐文章于 2024-02-23 00:30:05 发布
最新推荐文章于 2024-02-23 00:30:05 发布
阅读量3.5k 收藏 27
点赞数 7
文章标签： 跨域问题 CORS jsonp csrf 漏洞挖掘
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wy_97/article/details/107730864
版权 
知乎：Sp4rkW
GITHUB：Sp4rkW
B站：一只技术君
博客：https://sp4rkw.blog.csdn.net/
联系邮箱：getf_own@163.com

文章目录

前两周在90sec论坛上看到一篇挺有意思的文章，主要讲的是同源策略的问题，作者写的较为详细，其中有些内容也解决了我之前的一些疑问。但是，看百次不如自己动手去做一次，此外，b站也好久没有更新技术视频了。于是我决定去复现一下这篇文章的所有实验，并结合自己的一些经验，来聊一聊可能存在的一些漏洞该怎么挖掘与防御。视频的完整内容已经上传b站，各位看官可以移步观看，有账号的同学能给个一键三连就再好不过了~

漏洞挖掘中的同源策略 P1

漏洞挖掘中的同源策略 P2

PS：第三期视频因为我误删了环境虚拟机，懒得配置了，就没有做了，直接看文章吧~

一、同源策略

1、同源策略的定义

​ 同源策略限制从一个源加载的文档或脚本与另一个源的资源进行交互，是用于隔离潜在恶意文件的重要机制。不同源的客户端脚本在没有明确授权的情况下，不能读取对方资源。比如，浏览器执行javascript脚本时，会检查这个脚本属于哪个页面，如果不是同源页面，就不会被执行。

2、什么是同源

同源要求三个都相同：

  • 端口
  • IP
  • 协议
URL说明是否允许通信
http://www.a.com/a.js http://www.a.com/b.js同一域名下允许
http://www.a.com/lab/a.js http://www.a.com/script/b.js同一域名下不同文件夹允许
http://www.a.com:8000/a.js http://www.a.com/b.js同一域名，不同端口不允许
http://www.a.com/a.js https://www.a.com/b.js同一域名，不同协议不允许
http://www.a.com/a.js http://70.32.92.74/b.js域名和域名对应ip不允许
http://www.a.com/a.js http://script.a.com/b.js主域相同，子域不同不允许
http://www.cnblogs.com/a.js 1 http://www.a.com/b.js不同域名不允许

3、同源策略在保护什么

同源策略对于js的限制有3点：

（1）无法用js读取非同源的Cookie、LocalStorage 和 IndexDB 无法读取

​ 为了防止恶意网站通过js获取用户其他网站的cookie。

（2） 无法用js获取非同源的DOM

​ 如果没有这一条，恶意网站可以通过iframe打开银行页面，可以获取dom就相当于可以获取整个银行页面的信息。当然，iframe标签允许加载，可能会造成另外一个问题，点击劫持。点击劫持这里我就不解释了，详情见我之前的视频

https://www.bilibili.com/video/BV1i4411C7WP/

（3） AJAX 请求限制发送

​ 为什么要做这个请求限制呢？比如说我搭建了一个站点，我在我的页面中写入js请求，去请求百度修改账号头像。如果没有跨域的保护，我可以发送这个请求，并且你如果百度账号是登录状态，那你的头像就被我修改了。

二、环境搭建

1、服务器配置

名称系统IP 地址
Aubuntu server18192.168.1.113
Bubuntu server18192.168.1.115

更加详细的配置如图所示：

在这里插入图片描述

2、宝塔站点安装配置

之后直接给两个服务器安装宝塔，方便快速搭建php站点

wget -O install.sh http://download.bt.cn/install/install-ubuntu_6.0.sh && sudo bash install.sh

安装完成之后选择一套集成环境安装一下即可，我的话就选择了nginx这一套，ftp不需要，所以就没有安装了，传输文件可以使用winscp来解决

之后创建个站点

在这里插入图片描述
在这里插入图片描述

为了方便对比，我总共创建了三个web站点，分别是：

ip端口服务类型协议
192.168.1.11380基于php的web站点http
192.168.1.11580基于php的web站点http
192.168.1.11581基于php的web站点http

至此环境配置完成

三、同源策略限制js演示

原文作者总共给出了三个实验，分别是：

  • 基于iframe标签引入跨域站点页面的dom获取cookie
  • 测试ajax在不同同源策略下的表现
  • 基于iframe标签引入的页面的dom修改

由于第一个和第三个实验本质上是相同的，所以我合并起来进行演示

1、基于iframe引入页面的dom操作

构造两个页面，用于测试，首先我们来看引入页面的代码：

<!-- js-iframe-115.html -->


<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>js-iframe-115</title>
</head>
<body>
    <iframe id="myframe" src="http://192.168.1.115/js-iframe-115.php"> </iframe>
    <h2 id="A">使用iframe标签测试跨域访问非同源网站获取cookie测试</h2>
    <input type="button" onclick="changeStyle_1()" value="获取嵌入网站的cookie">
    <script>
        document.cookie = "ceshi6";

        function changeStyle_1() {
            var x = document.getElementById("myframe");
            var y = (x.contentWindow || x.contentDocument);
            if (y.document) y = y.document;
            alert(y.cookie);
        }
    </script>


    <h2 id="A">使用iframe标签测试跨域修改背景色</h2>
    <input type="button" onclick="changeStyle_2()" value="修改背景颜色">
    <script>
        function changeStyle_2(){
            var x = document.getElementById("myframe");
            var y = (x.contentWindow || x.contentDocument);
            if (y.document) y = y.document;
            y.body.style.backgroundColor = "#008800";
        }
    </script>
</body>
</html>

上面的两个部分，都是用iframe标签引入了http://192.168.1.115/js-iframe-115.php页面，作用分别是，提取这个站点的cookie与修改页面背景色。再来看下被引入页面的代码：

<!-- js-iframe-115.php -->


<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>js-iframe-115-php</title>
    <style>
    </style>
</head>
<body>
    <div class="container">
        <p>用于测试跨域读取cookie</p>
    </div>
</body>
</html>
<?php
    setcookie('name','king',time()+3600);
    setcookie('mail','muke@imooc.com',time()+3600);
    setcookie('addr','beijing',time()+3600);
?>

这里的代码比较简单，仅仅是设置cookie。接下来我们进行三组对照实验，我们将php文件放在115站点的80端口web服务下，之后在三个web服务中都放入html文件，这样我们就可以分别从同ip同端口，同ip不同端口，不同ip来进行测试。

1.1、相同ip相同端口

演示的动图如下：

在这里插入图片描述

可以看到在同源的情况下，我们可以很容易的通过js获取iframe标签引入的站点的dom，进而获取到cookie与修改页面背景色

1.2、不同ip

演示的动图如下：

在这里插入图片描述

可以看到在不同ip也就是不同源的情况下，js控制台会产生警告，当我们执行js事件企图获取到引入站点的dom的时候，控制台直接报错

1.3、相同ip不同端口

演示的动图如下：

在这里插入图片描述

对比不同ip的情况，我们可以发现，在不同端口的情况下，控制台没有告警，但是执行js的时候，依旧会报错，无法执行

这时候，问题来了，原文作者在这里实验出了一个非常有趣的结果

在这里插入图片描述

​ 就这个结果，我特地请教了原文作者，这里也非常感谢原文作者愿意和我沟通交流。最终我们发现，第一，这个图有问题，alert的是document.cookie，也就是当前站点的地址，所以会弹窗；第二，为什么会弹出设置在另一个端口对应web服务的cookie呢？这里就不得不提一个非常有意思的机制了

根据同源策略，cookie是区分端口的，但是浏览器实现来说，“cookie区分域，而不区分端口，也就是说，同一个ip下的多个端口下的cookie是共享的！“

演示动图如下：

在这里插入图片描述

​ 进一步搜索这个问题，我发现很多开发都在吐槽这个点，本地测试的时候非常恶心，cookie混乱。所以大部分开发在测试过程中都会给不同端口，同一ip的web服务分别分配不同的子域名，如test1.x.com，test2.x.com。这也就是为什么不同子域名明明对应ip是一个，但是还会被浏览器跨域策略所限制。

​ 这里其实引起了我的另一个思考，如果能找到一个站点的xss，同时获取了服务器的真实ip，那么我可以通过这个xss，拿到同ip不同端口的其他服务的cookie，这个思路有待之后实战测试一下。不过可能最大的限制在于，用户应该都是通过域名进行访问操作的，不过在特定站点都还有一些是通过ip直接访问

2、ajax跨域操作

首先构建两个用于测试的页面，我们先来看请求端的页面：

<!-- js-ajax-115.html -->


<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>js-ajax-115</title>
</head>
<body>
    <p>请求失败<p>
    <script>
        var url = "http://192.168.1.115/js-ajax-115.php";
        function createXMLHttpRequest() {
            if (window.XMLHttpRequest) {
                XMLHttpR = new XMLHttpRequest();
            } else if (window.ActiveXObject) {
                try {
                    XMLHttpR = new ActiveXObject("Msxml2.XMLHTTP");
                } catch (e) {
                    try {
                        XMLHttpR = new ActiveXObject("Microsoft.XMLHTTP");
                    } catch (e) {}
                }
            }
        }
        function sendRequest(url) {
            createXMLHttpRequest();
            XMLHttpR.open("GET", url, true);
            XMLHttpR.setRequestHeader("Content-Type", "text/html;charset=utf-8");
            XMLHttpR.onreadystatechange = processResponse; 
            XMLHttpR.send(null);
        }
        function processResponse() {
            if (XMLHttpR.readyState == 4 && XMLHttpR.status == 200) {
                document.write(XMLHttpR.responseText);
            }
        }
        sendRequest(url);
    </script>
</body>
</html>

这个页面总共有三个样式，我们结合被请求页面代码的来看

<!-- js-ajax-115.php -->

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>js-ajax-115-php</title>
    <style>
    </style>
</head>

<body>
    <div class="container">
        <?php
            if ($_COOKIE['user'] == 'test'){
                echo "<p>cookies满足,跨域请求页面测试</p>";
            }else{
                echo "<p>cookies不满足,跨域请求页面测试</p>";
            }
        ?>
    </div>
</body>
</html>

​ 在请求页面被加载的时候，如果js里面的ajax请求加载失败，会显示请求失；js执行成功却没携带cookie，则返回cookies不满足；js执行成功且携带cookie，返回cookies满足。下面我们来进行测试，将php文件放入115的默认80web服务下，html分别放入113,115默认的80web服务下，并手动给115站点赋予cookie键值对user-test。

在这里插入图片描述

2.1、相同ip

演示动图如下：

在这里插入图片描述

可以看到，在同源的情况下，ajax的请求发送成功，且请求时正常携带了cookie

2.2、不同ip

演示动图如下：

在这里插入图片描述

​ 可以看到这里的network对115服务请求有一个报错Provisional headers are shown，这个报错大部分都是因为跨域问题所引起的，这个报错代表浏览器阻止了ajax请求的发送。原文作者在这里提出了一个观点，说请求成功发送了，但是接收方拒绝接受了

在这里插入图片描述

​ 换成我这个实验，意思就是说113服务器的ajax成功执行并带回来数据，但是115并没有接受。这和我的实验结果再一次有所出入，于是我也用burp进行了测试。

在这里插入图片描述
在这里插入图片描述

​ 可以看到，我捕获到了两个流量，第一个是113的正常请求，第二个就是115的请求。但，需要注意的是，这里对115的请求并不是GET/POST，而是OPTIONS。那，什么是OPTIONS请求呢？

在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。

​ 注意，OPTIONS请求是浏览器给我们强行发送的，当浏览器通过服务器的返回包发现，服务器不接受你的跨域请求，于是接下来的实际跨域请求直接就不会发送了。

四、实际挖掘漏洞中可能遇到的跨域漏洞以及防御措施

​ 原作者的第四章是关于跨域策略在开发中的规避措施，规避措施实际上指的就是这里我结合我自己的挖洞经验，来演示一下一些漏洞的产生原因和修复手段。修复手段可能远不止这些，但是我在实际漏洞挖掘中，碰到这些情况可能我一般就直接放弃了跨域漏洞的挖掘。

1、跨域写漏洞

提前说明一下，不做csrf漏洞基本原理的详细演示了，如果下面的简单演示没有看懂的话，建议可以先去了解一下csrf再继续看后续内容。

首先我没来构建一个简单演示环境，后端服务器代买如下：

<!-- csrf-115.php -->


<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>csrf-115-php</title>
    <style>
    </style>
</head>
<body>
    <div class="container">
        <?php
        	header('content-type:text/html;charset=utf8');
            header('Access-Control-Allow-Origin:192.168.1.111');
            header('Access-Control-Allow-Methods:POST');
            header('Access-Control-Allow-Headers:x-requested-with,content-type,Accept');
            $myfile = fopen("demo.txt", "w");
            if ($_COOKIE['user'] == 'test'){
                $txt = "cookies满足   ".$_POST['data'];
                fwrite($myfile, mb_convert_encoding( $txt, 'UTF-8', mb_detect_encoding($txt)));
            }else{
                $txt = "cookies不满足  ".$_POST['data'];
                fwrite($myfile, mb_convert_encoding( $txt, 'UTF-8', mb_detect_encoding($txt)));
            }
            fclose($myfile);
        ?>
    </div>
</body>
</html>

这个后端对应的前端页面我直接忽略没写了，按正常逻辑，前端有一个表单，示意图如下：

在这里插入图片描述

​ 这一块设计的正常逻辑是，前端表单填写数据，后端php处理post传输过来的data数据，如果有cookie，则写入本地，并备注cookie满足；如果没有cookie，也写入本地文件，只不过会标注cookie不满足。按照漏洞挖掘的思路来说，这里我们首先测试的就是csrf漏洞，使用burp辅助构造poc页面如下：

<!-- csrfpoc.html -->


<html>
<body>
    <script>
        history.pushState('', '', '/')
    </script>
    <form action="http://192.168.1.115/csrf-115.php" method="POST">
        <input type="hidden" name="data" value="123456" />
        <input type="submit" value="Submit request" />
    </form>
</body>
</html>

​ 将php文件放在115服务器上，将html文件放在113服务器上（这里我直接忽略同ip的情况了，这就是正常的前后端页面，肯定可以执行），按照第三步得出的结论，我们会受到浏览器同源策略的限制。115的地址还是一样，我已经手动给了user-test键值对的cookie。演示动图如下：

在这里插入图片描述

再来看下我们服务器的本地文件：

可以看到，我成功构造了一次csrf攻击，同时可以看到同源策略限制的192.168.1.111完全没有任何作用，origin就是192.168.1.115。但完全没有受到影响，因为同源策略限制的是js，不限制表单。那这里应该怎么防御呢？三种较为简单的思路：

  • 在表单中增加一个csrf-token参数
  • 服务端校验referer来源
  • 将前端数据由表单发送修改为使用ajax发送的json类型数据，后端强校验json类型

前两个防御措施很容易理解，我们来具体聊一聊第三个防御措施。这个防御测试基于两个原理：第一，单纯依靠html表单无法发送json类型数据；第二，js会被同源策略所限制。下面我们来看更具体的例子
在这里插入图片描述

2、基于json格式的跨域写防御

首先，我们基于上一个实验，修改后端处理代码为接受json格式数据，并强检验Content-Type头需要设置为application/json，代码如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>csrf-strict-json</title>
    <style>
    </style>
</head>
<body>
    <div class="container">
        <?php
            header('Access-Control-Allow-Origin:http://192.168.1.113');
            header('Access-Control-Allow-Credentials:true');
            header('Access-Control-Allow-Headers:content-type');
            header('Access-Control-Allow-Methods:*');

            if($_SERVER["CONTENT_TYPE"] == "application/json"){
                $post_array=$GLOBALS['HTTP_RAW_POST_DATA'];
                //--解析Json，获取对应的变量值
                $obj=json_decode($post_array,TRUE);
                $data = $obj['data'];
                echo $data;
                $myfile = fopen("demo.txt", "w");
                if ($_COOKIE['user'] == 'test'){
                    $txt = "cookies满足   ".$data;
                    fwrite($myfile, mb_convert_encoding( $txt, 'UTF-8', mb_detect_encoding($txt)));
                }else{
                    $txt = "cookies不满足  ".$data;
                    fwrite($myfile, mb_convert_encoding( $txt, 'UTF-8', mb_detect_encoding($txt)));
                }
                fclose($myfile);
            }else{
                echo "不接收该类型传参";
            }  
        ?>
    </div>
</body>
</html>

因为做了强校验，所以使用burp直接构造的poc已经没有办法利用了。关于为什么无法利用，浏览器在很老的版本之前就已经开始禁用html表单发送json数据了，这里不做过多说明。那此时是不是安全了呢？并不是，我们可以通过js来发送json格式数据，构造页面如下：

<html>
 <head>
 <script style="text/javascript">
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "http://192.168.1.115/csrf-strict-json.php", true);
        xhr.setRequestHeader("Accept", "application/json, text/plain, */*");
        xhr.setRequestHeader("Accept-Language", "zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3");
        xhr.setRequestHeader("Content-Type", "application/json");
        xhr.withCredentials = true;
        xhr.send(JSON.stringify({
          "data": "json12300"
        }));
    }
   </script>
 </head>
  <body>
    
    <form action="#">
      <input type="button" value="Submit request" onClick="submitRequest()"/>
    </form>
  </body>
  
</html>

演示动图如下：

在这里插入图片描述

服务器的本地文件如下：

在这里插入图片描述

上图证明，可以利用js跨域再一次证明存在csrf漏洞，但我们需要注意一点，这里我将115的web服务跨域保护对113服务器解除了，并且允许跨域请求且携带cookie。

header('Access-Control-Allow-Origin:http://192.168.1.113');
header('Access-Control-Allow-Credentials:true');
header('Access-Control-Allow-Headers:content-type');
header('Access-Control-Allow-Methods:*');

这四行的代码的意思分别是：允许来自113的跨域请求，允许跨域请求携带cookie，允许跨域option预检验，接受一切请求类型数据包

相关的演示过程有点多，不继续截动图了，有兴趣的请自行验证这几行代码的作用

3、Access-Control-Allow-Origin:*是否存在漏洞

简单的修改一下上一个实验的代码为

header('Access-Control-Allow-Origin:*');

之后，我们重复上一个实验，演示动图如下：

在这里插入图片描述

可以看到我们这次被跨域保护给拦截了，用burp抓包看一下

在这里插入图片描述
在这里插入图片描述

可以看到，是允许所有域进行跨域的*，那为什么这里的option预检验确失败了呢？

https://fetch.spec.whatwg.org/#resource-requests

在这里插入图片描述

翻译一下，简单的意思就是说，如果是*，则不允许携带cookie，我们再来修改下poc页面的代码

// xhr.withCredentials = true;

加上注释，表明不携带cookie，演示动图如下：

在这里插入图片描述

服务器的本地文件如下：

在这里插入图片描述

可以看到，这次成功跨域了，但是cookie没有携带。综上，我们可以认为，跨域策略为*的时候其实并没有实际危害性，因为跨域请求不可以携带cookie，这基本上不会执行任何敏感操作。

4、跨域读漏洞

跨域读主要有两种表现：

  • cors保护机制存在问题，仅仅通过csrftoken保护了存在写漏洞的地方
  • jsonp跨域读取

cors读的实验不演示了，参考之前的通过iframe引入页面的dom操作，这就是漏洞其中的一种表现。jsonp跨域的话，我前年的一篇博客已经做了较为详细的演示了，详见：从Ajax聊一聊Jsonp hijacking

5、跨域问题的防御

结合我平时的经验，一般的防御措施以及可能的问题如下：

1、CORS跨域机制完善+所有接口强制POST Json格式

这个说起来很简单，做起来其实挺难的，随着业务的拓展，很多接口开发一不注意，为了方便就直接改了CORS的保护机制，而且一般CORS的保护机制是单独一个模块，引用对整个站点生效的。所以仅仅依靠CORS机制，很容易出问题。

2、CSRF-Token保护机制

这个对付跨域写漏洞很好用，但是跨域读，很容易忽略保护

3、Referer检测机制

这个我个人认为是最简单，但应用起来最方便的一个保护机制了。但是如果存在比如xss漏洞，url重定向问题，甚至referer检验不严格等等，这个机制也就完全失效了

4、自定义header头

跨域的时候header头是不可以控制的，当然，如果服务器的cors策略接收这个header，还是可以继续跨域操作的

不同机制适用于不同场景，结合起来可能会有更好的效果。

文章到此结束，暂时没想到还有什么没有写的了，如果你有任何问题，欢迎与我进行交流~

五、文章参考来源

浏览器同源策略是什么？没有同源策略会怎么样？

对同源策略的进一步研究

跨域请求如何实现自定义 header？

再遇CORS – 自定义HTTP header的导致跨域

JSONP跨域和CORS跨域

Access-control-allow-origin:*并没有实际危害

Sp4rkW
关注
专栏目录
实战分析和精华总结：CORS跨域资源共享漏洞数据劫持、复现、分析、利用及修复过程
代码讲故事
12-03 1625
实战分析和精华总结：CORS跨域资源共享漏洞数据劫持、复现、分析、利用及修复过程。 CORS跨域资源共享漏洞与JSONP劫持漏洞类似，都是程序员在解决跨域问题中进行了错误的配置。攻击者可以利用Web应用对用户请求数据包的Origin头校验不严格，诱骗受害者访问攻击者制作好的恶意网站，从而跨域获取受害者的敏感数据，包括转账记录、交易记录、个人身份证号信息、订单信息等等。
多模态大模型：技术原理与实战 全球多模态大模型介绍
AI天才研究院
06-11 1120
关键词：多模态大模型、深度学习、计算机视觉、自然语言处理、跨模态学习、迁移学习、人工智能随着人工智能技术的飞速发展，多模态大模型已经成为了当前AI领域最热门的研究方向之一。多模态大模型能够同时处理和理解多种类型的数据，如文本、图像、音频和视频等，这为AI系统在复杂场景下的应用提供了更加强大和灵活的能力。本文将深入探讨多模态大模型的技术原理，介绍其实战应用，并对全球主要的多模态大模型进行全面的介绍和比较。
线上问题数量大、难复现时，如何提升问题的复现率
qq_42905388的博客
02-23 860
用户提供的信息充足（截图、录屏或详细文字等有效信息以及机型、日志等辅助信息）表明了错误比较显著，同时操作链路比较完整，则可以通过场景链路复现。
cookie跨域_跨域问题的复现与整理
weixin_39721853的博客
11-21 471
知乎：Sp4rkWGITHUB：Sp4rkWB站：一只技术君博客：https://sp4rkw.blog.csdn.net/联系邮箱：getf_own@163.com文章目录一、同源策略1、同源策略的定义2、什么是同源3、同源策略在保护什么二、环境搭建1、服务器配置2、宝塔站点安装配置三、同源策略限制js演示1、基于iframe引入页面的dom操作1.1、相同ip相同端口1.2、不同ip1.3、相...
前端跨域问题复现代码
qq_39630624的博客
09-18 176
直接引用，修改接口地址及传参即可 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <ti
CORS跨域资源共享漏洞的复现、分析、利用及修复过程
热门推荐
weixin_46622976的博客
12-27 1万+
CORS漏洞测试
SpringBoot SSO 单点登录权限管理，轻量级，OAuth2实现，支持跨域，支持前后端分离，支持分布式部署.zip
最新发布
08-20
项目工程资源经过严格测试可直接运行成功且功能正常的情况才上传，可轻松copy复刻，拿到资料包后可轻松复现出一样的项目，本人系统开发经验充足（全栈开发），有任何使用问题欢迎随时与我联系，我会及时为您解惑，...
【Recsys2021】推荐系统论文整理和导读
发现问题，并解决问题，批判性思维
10-31 1960
文章目录一、按照推荐系统研究方向分类1.1 信息茧房和回音室1.2 探索与利用1.3 偏差与纠偏1.4 冷启动1.5 评估体系1.6 会话/序列推荐1.7 隐私保护1.8 对抗与攻击1.9 对话推荐系统1.10 可解释性推荐1.11 跨域推荐1.12 基于视觉的推荐1.13 组推荐/用户物品分层推荐1.14 推荐系统交互设计二、按照推荐技术分类2.1 协同过滤2.2 图学习2.3 强化学习2.4 度量学习2.5 联邦学习2.6 架构/训练/优化三、实验性质的文章总结 以下文章来源于蘑菇先生学习记 ，作者蘑菇
首次使用VUE搭建简单项目问题汇总
Zlantan的博客
07-01 261
* 以下内容为学习VUE全家桶时遇到的问题整理，学习中复现的网站为‘卖座电影’移动端，问题的顺序不是线性的，只是起思路整理和提醒的作用，许多具体问题还要配合文档观看。* 1. *跨域请求问题：* 跨域请求问题的解决方案主要有三种，JSONP、cors方法和服务代理（反向代理），目前JSONP使用较少，这里详细说一下cors方法和服务代理。 Cors方法：在服务端设置响应头”Access-Control-Allow-Origin:”这样所有人都可以向该服务器请求数据，通配符也可以替换成后端允许请求的域名。（当
跨域问题的产生及解决方法
weixin_34309435的博客
10-31 149
域(Domain)是Windows网络中独立运行的单位，域之间相互访问则需要建立信任关系(即Trust Relation)。信任关系是连接在域与域之间的桥梁。当一个域与其他域建立了信任关系后，2个域之间不但可以按需要相互进行管理，还可以跨网分配文件和打印机等设备资源，使不同的域之间实现网络资源的共享与管理。 有一种简明的说法来解释广域跨域：跨域访问，简单来说就是 A 网站的 javascript ...
偶发问题复现方法
qingshenwangzi_Ivan的博客
08-08 4070
作为一名测试工程师，发现问题并不难，难的是去重现问题，特别是那些偶发的问题。今天我们就来扒一扒如何去复现这些偶发问题。 其实严格来说，偶发问题是不存在的，偶发问题都有必发路径，只是这些路径隐藏太深，不大好发现，而且就算是偶发问题概率很低，产品到了海量的客户手中，问题就变成必发了。 话不多说，现在就来分享一下自己复现偶发问题的方法： 1、记录问题。对于偶发问题，我们首先要做好的就是记录。问题出现...
部署问题复现
qq_41815731的博客
08-10 321
部署问题复现后端JDK版本问题解决方法前端遇到的问题解决方案 后端 JDK版本问题 ① 客户电脑的JDK版本低（比如JDK1.5），实际需要1.8的版本 ② 64位的JDK不能装在32位机器上 ③ 在网上下载32位的JDK在客户机上安装会出现与已配置环境变量的JDK1.5冲突的问题（windows下安装多个java版本出现’has value ‘1.8’,but’1.5’ is required’问题，网上解决方案： http://www.xmhzd.com/study/article/view-1012.
跨域问题，都能看懂的例子
qq_43169491的博客
01-19 457
跨域问题：A域名访问B域名的数据 域名或者请求端口或者协议不一致的时候，就跨域了。 www.tuzy.com www.tuzy.cn 跨域 www.tuzy.com www.tuzy.com/user/list 不跨域 www.tuzy.com:1100 www.tuzy.com:1808 跨域 https://www.tuzy.com http://www.tuzy.com/user/list 跨域 ...
Ajax跨域问题及解决方案
weixin_34292959的博客
04-30 168
复现Ajax跨域问题 做两个简单的小项目复现Ajax跨域问题. 后端语言使用Java 首先是一个简单的订单系统, 通过访问/loadOrderList, 最终以json串形式返回订单集合. 该项目使用Tomcat发布在7070端口. @RequestMapping("/loadOrderList") @ResponseBody public List<Order> loadOrde...
跨域问题详解及解决方案
无简介
04-27 8230
随着 Web 技术的不断发展，前后端分离的开发模式逐渐成为主流。在这种模式下，前端和后端分别独立开发，前端与后端通信的方式多为使用 Ajax 发送 HTTP 请求。然而，由于浏览器的安全策略限制，可能会出现跨域问题，导致请求失败。什么是跨域问题？为什么会出现跨域问题？什么情况下会出现跨域？如何解决跨域问题？代码示例跨域问题指的是在 Web 应用程序中，由于同源策略的限制，导致浏览器无法发送跨域请求，也无法获取跨域响应的问题。
复现-定位问题的关键步骤
u014511571的博客
10-24 678
复现对于解决问题,相当于debug对于开发,是事半功倍的利器准确的掌握复现的工具使用,可以极大的提升问题的解决质量和解决效率。
Ajax基础与跨域问题详解
本文将深入探讨Ajax及其在处理跨域问题中的应用，首先介绍什么是Ajax。Ajax，全称为Asynchronous JavaScript and XML，是一种前端开发技术，允许网页在不重新加载整个页面的情况下，与服务器进行异步数据交换，从而...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值