如何加密抓包加密

2023-02-23 16:55 20次浏览 攻略

关注Java领域的优质技术号,作者:欢迎关注胖王朝。

内容概述。png

目的

面试很多时候都是dash red,比如数据加密,比如HTTPS,也就是不管是从事前端还是后端,数据加密和HTTPS都必须掌握。

数据加密

第一,为什么我们要加密数据?HTTP中的所有访问都是明文,只要能够听到网络上的所有请求数据,就是透明的。例如,所有浏览器的开发人员工具都可以清楚地看到提交表单的参数和地址。Android和iOS也经常以抓包的方式模仿其他APP。例如,Charles是Mac上常用的捕获工具。

提交表单加密

由于篇幅有限,这里暂时以JS为例

例如,我们常用的JS插件如图:所示。min结束的所有代码都可能混乱。

这个JS都是压缩的。他去掉注释和空格,将变量名改为短变量名,使我们难以阅读。

其实目前没有绝对的安全性。安全本来就是一场攻击战,所以我们能做的只有增加解密成本,防止解密。例如,可以使用JS混淆。图3360

从这里可以看出,简单的代码加密压缩后会变得如此复杂。但是细心的同学发现旁边有一个解密按钮。所以这种方式的缺点是这种加密方式是可逆的。也就是说,一旦收到加密的JS,就可以解密

对称加密算法

此时,回想一下我们以前是如何加密的。我们都在前台按一定的规则加密,后台按这个规则解密。那能不能安全一点?

比如我们加密的时候,后台请求随机数,这个随机数是前台加密和后台解密的关键,这个叫密钥。

让我们用图画来描述这个过程:

在序列号3中,我们知道,如果不能获得随机数(密钥),就无法解密,但如果别人能收到呢?因此,这种对称加密最大的困难是如何有效地隐藏密钥,以及如何在后台管理密钥池。

不对称加密算法

不对称加密算法是我们平时最常用的。那么,什么是不对称加密算法呢?

我们是这样想象的,用什么算法加密后,反向解密有解不开的吗?例如,原来的密码是123,我们的加密算法成为第一名,即234,得到234,那么我们各减去第一名也得不到123,计算123需要另一种算法。

从上面的例子可以看出,这种加密算法和解密算法是完全不同的。这种加密思想是不对称加密算法的一种方法。

另一种方法是,我们最常用的方法。其中这种不对称在钥匙上。在以前的对称加密算法中,缺点是前台和后台获得的钥匙相同。

不对称加密算法使用公钥/私钥,使用加密算法(明文、公钥)生成密文。这个密语即使知道公钥和加密算法,也无法解密。需要与此公钥相对应的私钥才能解密。

也就是说,公钥只能从私钥中解密。私钥是加密的,只能从公钥解密,所以我们的公钥可以自由地对外公开。只需隐藏私钥。具体实现如图所示。

因此,这种加密算法的缺点是,只要收到私钥,就可以解开所有密文。

在非对称加密算法中,RSA加密算法也很常用。RSA由作者的首字母组成。由于篇幅有限,这里介绍的不多。

HTTPS

HTTPS简介

HTTPS相信大家不会陌生。那么,如何知道HTTPS呢?我们从三个方面开始。也就是说,什么是什么,有什么用,为什么需要?

什么,

HTTPS是网络协议,是HTTP协议和TCP/IP协议之间的协议(图)。所以HTTPS实际上不是我。

们写代码的时候需要处理的东西,他是browser和应用服务器(例如Tomcat)需要去处理的一个东西.但是,如果你是做Android或者iOS客户端,要发送和处理一个HTTPS请求的时候,也需要做额外的处理

有什么用:

能够让浏览器明确访问的网站是安全网站一旦HTTPS连接成功,浏览器和服务器之间的数据传输全部是加密传输(对称加密)

为什么需要

HTTP上传输的所有数据都是明文,于是出现了SSL(Secure Sockets Layer安全套接字层)协议用于对HTTP协议进行加密传输, HTTP + SSL = HTTPS;IETF对SSL进行了升级,就是TLS(Transport Layer Security),其实我们现在说的HTTPS都是使用的是TLS;

HTTPS的工作原理

假设我们访问,这之间的握手协议如下图

HTTPS的工作原理.png

文字解读:

  • 浏览器(客户端)将自己支持的一套加密规则(SSL版本号,加密算法版本,哈希算法版本)发送给网站,网站接收到浏览器支持的算法版本,选择一组对应的算法版本
  • 网站把网站地址,加密公钥,证书颁发结构等信息以SSL证书的形式发送给客户端
  • 客户端接收网站发送的证书后,需要验证该证书的合法性:从底层的SSL证书向上层证书进行验证,只要在证书链中任意一级证书是可信的,那么这个证书是可信的
  • 得到SSL证书中的域名,和当前访问网站进行比对,比对通过,浏览器信任该站点
  • 浏览器生成一个随机数:random,并使用证书中的公钥进行加密(非对称算法),伪代码如:RSA(SSL证书中的公钥,random)->密文A
  • 浏览器生成一个握手信息,如:"toby", 并使用确定的HASH算法生成一个hash值,伪代码如:HASH("toby")->hash码
  • 使用random对toby握手信息进行加密(对称算法),伪代码如:encore(random,"toby")->密文B
  • 把密文A,hash码,密文B全部传给网站
  • 服务器接收到密文A、hash码、密文B后,使用服务器端SSL证书中的密钥对密文A进行解密,伪代码如:RSA(SSL证书中的密钥,密文A)->random
  • 使用加密算法对密文B进行解密,伪代码如decode(random,密文B)->握手信息
  • 再用hash算法算出握手信息的hash值,伪代码如HASH(握手信息)->hash码
  • 对比这个hash码和传过来的hash码是否一致,如果一致,服务器端再生成一个握手信息比如"hello"对服务器端的一个握手信息进行加密,伪代码如encode(random,"hello")->密文
  • 对握手信息进行hash计算,伪代码如hash("hello")->hash码
  • 把hash码和密文传给浏览器
  • 客户端接收到密文和hash码
  • decode(random,密文)->握手信息
  • HASH(握手信息)->hash码
  • 对比hash码,如果一致,随机码都互相验证过,并且都各自存放好了,此时,两边都完成了HTTP交互,现在的结果是,客户端和服务器都有一个random

接下来的请求就全部使用encode(random,明文)进行加密传输了,服务器端则使用decode(random,密文)->明文,此时,这个加密算法就是一个对称加密算法了,这个解析出来的明文就会交给HTTP协议,所以我们应用拿到的是明文

线上充值原理

首先这里有三个名词,一个是xx平台就是我们要充值的平台,还有一个是第三方支付平台,这样的平台有很多,比如大家都知道的支付宝,财付通,网银在线等等,还有一个是银行,这个大家都懂

我一向是都是喜欢先粗暴地上流程图,如下:

文字解读:

首先,xx平台需要和第三方平台签订协议,这样xx平台就能得到一个在第三方平台的账户,那么我们开始充值流程

1.用户开始在xx平台进行充值

2.用户由xx平台的在线充值界面跳转到第三方支付平台,这个时候需要带上username、password、apikey以便第三方平台知道我们来自哪个平台,同时还要带上一个唯一的id作为交易流水

3.一般有快速支付和网银支付,这里拿网银支付举例,当点击网银支付的时候,跳转到银行的转账界面,这个时候要注意,这个接口是银行和第三方支付平台对接的,所以跳转的时候还要带上平台的唯一标识

4.我们假设转账成功,那么这个时候,钱是转到了第三方支付平台,而不是xx平台

5.第三方平台需要为银行提供一个接口,进行回调,告诉第三方支付平台,流水号的处理结果

6.这个时候,将充值金额累加到xx平台的账户中,但是这个只是虚拟现金流的增加,钱还在第三方支付平台的银行账户中

7.xx平台需要为第三方平台提供一个接口,处理回调,告诉xx平台,流水号的处理结果

8.假设回调成功状态,xx平台将在用户的账户把钱增加,但是这个时候,也只是虚拟现金流的增加,此时钱还是在第三方支付平台的账户

9.第三方支付平台会在一个结算周期(一般是两天到三天),他会自动地把这段时间之内交易成功的钱打到xx平台上

所有第三方支付平台的原理都是以上流程,所以,对于我们xx平台而言,只需要做两件事

  • 页面跳转,把充值信息告诉第三方支付平台
  • 写一个回调的接口,接收交易情况

来源:https://www.jianshu.com/p/2cb959529c96

相关推荐