中间人攻击介绍

中间人攻击(man-in-the-middle attack, abbreviated to MITM)，顾名思义，就是攻击者躲在通信双方之间，窃听甚至篡改通信信息，而这个攻击是不可见的，通信双方并不知道消息已经被截获甚至篡改了

这个图片很形象哈

中间人攻击原理 中间人攻击常见的两种方式为ARP欺骗和DNS欺骗

1. ARP欺骗

ARP，地址解析协议，将接受到的IP地址解析为MAC地址，从而实现信息转发和传输。

每个终端都有一个ARP缓冲区，里面保存IP地址和对应的MAC地址。由于以太网中终端无法鉴别ARP中给出的IP地址和对应MAC地址的真伪，而是直接将其保存在ARP缓冲区中，这就为实施欺骗提供了可能。

ARP协议工作原理 在以太网中，数据传输的目标地址是MAC地址，一个主机要和另一个主机进行直接通信，必须要知道目标主机的MAC地址。 计算机使用者通常只知道目标机器的IP信息，“地址解析”就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。 简单地说，ARP协议主要负责将局域网中的32为IP地址转换为对应的48位物理地址，即网卡的MAC地址，保障通信顺利尽心。

ARP欺骗原理 计算机通信用IP地址，在以太网中，主机传递信息用IP地址及MAC地址 （硬件地址）。主机之间知道彼此的IP地址，但不知道对方的MAC地址。在传递信息时，发送方得先问ARP找到对方的MAC地址才能发送。 ARP向局网中的所有主机广播询问接收方的MAC地址。这个询问 (ARP Request) 包含了发送方的IP、MAC地址，黑客若在这个局网中，也会收到ARP Request, 而得知发送方的地址。 从偷听各个主机所发送的ARP Request, 黑客知道了它们的的MAC地址，就可以冒充别的主机，进行欺骗活动，截取数据包。

攻击过程

如果终端A想要截获其他终端发送给终端B的IP分组，在发送的ARP请求报文中给出IP B和MAC A的绑定项，其他终端在ARP缓冲区中记录该绑定项后，如果向IP B传输IP分组，就会传输给MAC地址为MAC A的黑客终端。 ARP欺骗过程

1. 每个主机都用一个ARP高速缓存存放最近IP地址到MAC地址之间的映射记录。
2. 默认情况下，ARP从缓存中读取IP-MAC条目，缓存中的IP-MAC条目是根据ARP响应包动态变化的。
3. 要网络上有ARP响应包发送到本机，即会更新ARP高速缓存中的IP-MAC条目。
4. 攻击者只要持续不断的发出伪造的ARP响应包就能更改目标主机ARP缓存中的IP-MAC条目，完成ARP欺骗。

如何防御

因为终端无法鉴别，所以需要交换机鉴别ARP请求和响应报文中IP地址和MAC地址的真伪，交换机只转发正确的ARP请求和响应报文。

静态配置ARP映射，静态绑定IP和MAC地址

2. DNS欺骗

原理很简单，DNS就是实现IP地址和域名的相互转换，一般用户为了方便记忆，都是使用的域名来访问网页。当攻击者悄悄地将该域名对应的IP地址替换成他自己搭建的某个网站，就可以骗取用户输入他们想得到的信息，类似于钓鱼网站。

防御方法

1. 公钥基础建设PKI：使用PKI相互认证机制，客户端验证服务器，服务器验证客户端。如果只验证服务器，会造成SSL握手环节的漏洞，如果相互认证的话更为安全。
2. 延迟测试：使用复杂加密哈希函数进行计算以造成数十秒的延迟，如果双方通常情况下都要花费20s来计算，并且整个通讯花费了60s才到达对方，这就表明存在第三方中间人。
3. 使用其他形式的密钥交换方式。

什么是中间人攻击？

中间人攻击发生在第三方不知道合法参与者的情况下拦截数字对话时。此对话可以发生在两个人类用户、一个人类用户和一个计算机系统或两个计算机系统之间。

在任何这些情况下，攻击者都可能只是简单地窃听对话以获取信息（考虑登录凭据、私人账户信息等）。或者他们可能会模拟其他用户来操纵对话。在后一种情况下，攻击者可能会发送错误信息或共享恶意链接，这可能会导致系统崩溃，或为其他网络攻击打开大门。通常情况下，合法用户不会意识到他们实际上正在与非法第三方通信，直到发生损害以后才意识到。

中间人攻击的一个例子是会话劫持。其他类型的会话劫持攻击包括站点脚本、会话侧劫持、会话固定和暴力攻击

中间人攻击是怎样的？

执行中间人攻击需要黑客访问用户的连接。最常见的方法之一是创建一个公共的wifi热点，附近的任何人都可以加入，不需要密码。一旦用户加入这个网络，黑客就可以访问他们所有的数字通信，甚至记录基建，充当中间人。

公共wifi的例子是发动中间人攻击最常见和最简单的方法，但这并不是唯一的方法。其他常见方法包括：

将用户引导到假网站：黑客可以通过IP或DNS进行欺骗，将用户引导到假网站，而不是他们的预期的网站。当黑客更改IP地址中的数据包头时，就会发生IP欺骗，而当黑客访问DNS服务器并更改网站的DNS记录时，就会发生DNS欺骗。在哪种情况下，用户最后都会访问到黑客设置的假网站（在那里他们可以捕获所有信息），尽管它看起来非常真实。

变更数据传输路径：黑客可以通过进行ARP欺骗来重新路由通信的目的地。当黑客将其MAC地址连接到属于参与通信的合法用户之一的IP地址时，就会发生这种情况。一旦他们建立连接，黑客就可以接收合法用户IP地址的任何数据。

现实生活中一个人处于中间人攻击的例子是什么？

不幸的是，中间人攻击很常见。这种攻击的一些最著名的例子包括：

欧洲的企业银行账户盗窃案

2015年，欧洲当局逮捕了49名嫌疑人，他们在欧洲各地使用中间人攻击实施了一系列银行账户盗窃案。该组织通过访问企业电子邮件账户，监控通信来查看付款交易，然后将这些交易转移到自己的账户，从欧洲公司窃取了大约600万美元。这次攻击包括网络钓鱼的尝试，以及建立起来旨在看起来真实的假网站。

移动银行应用程序的错误证书使用情况

2017年，研究人员发现了包括汇丰银行、NatWest银行、Co-op、桑坦德银行和爱尔兰联合银行等主要银行在移动应用中使用的认证技术的一个缺陷。该缺陷意味着，与合法用户在同一网络上的黑客可以通过未正确验证应用程序的主机名来访问登录用户名、密码和Pin等登录凭据。

有了这种访问，黑客可以让中间人攻击者查看和收集信息，假冒合法用户采取行动，甚至启动应用内网络钓鱼攻击。有趣的是，在这种情况下提供访问权限的弱点源于处理证书的过程管理不当，这些过程实际上是为了提高安全性。

Equaxl域安全故障

2017年，美国最大的信用报告机构之一Equifax成为无安全域名连接中间人攻击的受害者，导致超过1亿消费者的个人信用信息被盗。该攻击始于Equifax未能修复其使用的开发框架中的一个漏洞，该漏洞允许黑客将恶意代码插入到HTTP请求中。从那里，黑客能够访问内部系统，并窃听用户会话，收集各种信息长达数月。

iOS 防止手机设置代理进行抓包

方法一 客户端进行判断是否设置了代理(对测试人员不友好)

+ (BOOL)getProxyStatus {
    NSDictionary *proxySettings = (__bridge NSDictionary *)((__bridge CF_CONSUMED CFTypeRef)((__bridge NSDictionary *)CFNetworkCopySystemProxySettings()));

    NSArray *proxies = (__bridge NSArray *)((__bridge CF_CONSUMED CFTypeRef)((__bridge NSArray *)CFNetworkCopyProxiesForURL((__bridge CFURLRef)[NSURL URLWithString:@"http://www.baidu.com"], (__bridge CFDictionaryRef)proxySettings)));
    NSDictionary *settings = [proxies objectAtIndex:0];

    NSLog(@"host=%@", [settings objectForKey:(NSString *)kCFProxyHostNameKey]);
    NSLog(@"port=%@", [settings objectForKey:(NSString *)kCFProxyPortNumberKey]);
    NSLog(@"type=%@", [settings objectForKey:(NSString *)kCFProxyTypeKey]);

    if ([[settings objectForKey:(NSString *)kCFProxyTypeKey] isEqualToString:@"kCFProxyTypeNone"])
    {
        //没有设置代理
        return NO;
    }
    else
    {
        //设置代理了
        return YES;
    }
}

另外，对于autorelease，如果项目设置了ARC，可以在Target－》Build Phase－》Compile Source中将相应的非ARC文件，
Compiler Flag改为-fno-objc-arc即可。

2. 客户端本地做证书校验,并且设置不仅仅校验公钥,设置完整的正式校验模式

1. 把证书机构签完的公钥证书放到工程里名称为"server.cer"

2. 设置AFSSLPinningMode

typedef NS_ENUM(NSUInteger, AFSSLPinningMode) {
    AFSSLPinningModeNone,//(默认级别)，客户端无条件信任任何下发的公钥证书
    AFSSLPinningModePublicKey,//客户端本地去验证服务端下发的公钥证书的 public keys部分。如果正确才通过
    AFSSLPinningModeCertificate,//客户端本地去验证服务端下发的公钥证书的所有部分。如果正确才通过
};

使用AFSSLPinningModePublicKey和AFSSLPinningModeCertificate方法基本可以防止青花瓷等的证书攻击

+(AFSecurityPolicy*)customSecurityPolicy
{
    // /先导入证书
    NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"server" ofType:@"cer"];//证书的路径
    NSData *certData = [NSData dataWithContentsOfFile:cerPath];
    // AFSSLPinningModeCertificate 使用证书验证模式 (AFSSLPinningModeCertificate是证书所有字段都一样才通过认证，AFSSLPinningModePublicKey只认证公钥那一段，AFSSLPinningModeCertificate更安全。但是单向认证不能防止“中间人攻击”)
    AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
    // allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO
    // 如果是需要验证自建证书，需要设置为YES
    securityPolicy.allowInvalidCertificates = YES;

    //validatesDomainName 是否需要验证域名，默认为YES；
    //假如证书的域名与你请求的域名不一致，需把该项设置为NO；如设成NO的话，即服务器使用其他可信任机构颁发的证书，也可以建立连接，这个非常危险，建议打开。

    //置为NO，主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。
    //如置为NO，建议自己添加对应域名的校验逻辑。
    securityPolicy.validatesDomainName = YES;
    NSSet<NSData*> * set = [[NSSet alloc]initWithObjects:certData  , nil];
    securityPolicy.pinnedCertificates = set;

    return securityPolicy;
}

所有方法都是有漏洞的，iOS的app够安全，但是圈内依然有一群逆向工程师

方法1中在使用Class-Dump还是能够找到方法并且运行时替换或者直接hook方法进行修改返回逻辑，动态库注入方式，再使用企业签名把ipa包进行重新签名ios-app-signer，fir发布。

方法2中在逆向工程师眼里也是很简单破解的，app砸壳，再显示包内容，依然可以直接把你证书放在青花瓷中使用。

只是提高了破解难度，有树叶遮羞总比裸露在外面好一点