HTTP协议授权访问

HTTP中带授权要求的处理机制。有些URL访问需要具有权限否则返回401的错误,因此客户端需要在HTTP的请求头中带上授权的用户和密码;或者当我们使用HTTPS协议时,一旦服务器证书不具备信任则需要客户端确认是否信任此服务器证书;或者用HTTPS协议当服务端也需要客户端提供证书时;或者我们是通过代理服务器来请求HTTP的,我们需要提供代理服务器的用户和密码,我们称这些情况称为服务端要求客户端接收挑战。

当我们使用NSURLConnection来请求需要挑战的页面的时delegate会先调用协议函数:

  • (void)connection:(NSURLConnection*)connectionwillSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge。

也就是如果有需要认证时不会先调用didReceiveResponse,而是先调用上面的函数,下面介绍NSURLAuthenticationChallenge类,这个类是认证挑战类,也就是要求客户端进行挑战,要接收挑战也就是客户端提供挑战的凭证(用户和密码,或者客户端证书,或者信任服务器证书,或者代理),IOS提供了一个NSURLCredential的类来表示挑战凭证。可以通过如下函数来建立挑战凭证

//通过用户密码建立凭证,这种用于401错误的挑战凭证和代理的挑战凭证

  • (id)initWithUser:(NSString*)user password:(NSString *)passwordpersistence:(NSURLCredentialPersistence)persistence;

//这种是要求客户端提供证书来建立的挑战凭证,用于服务器要认证客户端的情况,我们需要从钥匙串中得到一个客户端证书。

  • (id)initWithIdentity:(SecIdentityRef)identitycertificates:(NSArray *)certArraypersistence:(NSURLCredentialPersistence) persistence

//这种要求客户端的对服务器的信任来建立凭证,所谓SecTrust用来描述信任某个证书用来做什么的东西,比如一个证书可以用来做SSL,用来做签名,邮件安全(这个证书以及可以用来做什么来构造一个信任)

-(id)initWithTrust:(SecTrustRef)trustNS_AVAILABLE(10_6,3_0);

上面的2中证书中都有一个persistence值,这是一个枚举值用来描述这个凭证的保存策略,一共有三种:

NSURLCredentialPersistenceNone, //不保存,只请求一次。

NSURLCredentialPersistenceForSession, //只在本次会话中有效

NSURLCredentialPersistencePermanent //永久有效,保存在钥匙串中,其他也有效

为什么服务器信任的凭证不需要保存到存储中,原因是服务器信任的凭证总是从服务器下发给客户端的(可以这么理解吗?)

为什么要有保存策略呢?想想如果我们不保存的话我们每次都要进行用户手动处理太麻烦了,因此系统提供了一个地方来保存这些凭证,这样我们的挑战对象NSURLAuthenticationChallenge就可以根据特殊的信息(后面说明)来获取这些凭证而不必要每次都需要手动处理,这个保存的地方叫做NSURLCredentialStorage是一个凭证存储类,这个类提供一个单例的方法来访问凭证存储对象。我们知道一个挑战是服务器端向客户端发起的,所以提供一个凭证是根据服务端要求的信息来建立的,我们的挑战类NSURLAuthenticationChallenge根据服务端要求的挑战方式,从凭证存储类NSURLCredentialStorage中获取一个具体的凭证对象,然后接收挑战。而服务器要求的挑战方式我们用一个类NSURLProtectionSpace叫做保护空间来描述。那么保护空间里面有哪些信息呢?可以肯定的是包括挑战的方式(401授权,客户端证书,服务端要求信任等,如果是这个则会提供一个SecTrust对象)、服务器的URL地址,端口号,协议等等。确实如此,一个NSURLProtectionSpace提供如下信息:

//401的认证方式的realm字段的值

  • (NSString*)realm;

//401的认证方式,指定是否密码发送安全。

-(BOOL)receivesCredentialSecurely;

//代理授权

-(BOOL)isProxy;

//服务端主机地址,如果是代理则代理服务器地址

-(NSString *)host;

//服务端端口地址,如果是代理则代理服务器的端口

-(NSInteger)port;

//代理类型,只对代理授权,比如http代理,socket代理等。

-(NSString *)proxyType;

//使用的协议,比如http,https, ftp等,

-(NSString *)protocol;

//最关键字段,指定授权方式,比如401,客户端认证,服务端信任,代理等。

-(NSString *)authenticationMethod;

//客户端认证,是指定可接受的客户端证书列表??表示只有这些证书才可以??

-(NSArray *)distinguishedNames NS_AVAILABLE(10_6,3_0);

//用于服务端信任,指定一个信任对象,可以用这个对象来建立一个凭证。

-(SecTrustRef)serverTrust NS_AVAILABLE(10_6,3_0);

保护空间的建立提供2个方法:

  • (id)initWithHost:(NSString*)host port:(NSInteger)port protocol:(NSString *)protocolrealm:(NSString *)realm authenticationMethod:(NSString*)authenticationMethod;

//代理的保护空间

-(id)initWithProxyHost:(NSString*)host port:(NSInteger)port type:(NSString *)type realm:(NSString*)realm authenticationMethod:(NSString *)authenticationMethod;

好了有了保护空间类,也凭证类我们就可以把信息从凭证空间读取或者保存了,凭证空间提供了如下的方法:

//根据保护空间得到凭证对象字典,这个字典的key是用户名,而value是NSURLCredential

-(NSDictionary *)credentialsForProtectionSpace:(NSURLProtectionSpace*)space;

//所有凭证对象字典,key是保护空间,value是一个字典,其中value的key是用户名字,value是凭证

-(NSDictionary *)allCredentials;

//保存凭证

-(void)setCredential:(NSURLCredential*)credential forProtectionSpace:(NSURLProtectionSpace *)space;

//删除凭证

-(void)removeCredential:(NSURLCredential*)credential forProtectionSpace:(NSURLProtectionSpace *)space;

//设置某个保护空间的默认凭证

-(NSURLCredential*)defaultCredentialForProtectionSpace:(NSURLProtectionSpace *)space;

//获取某个凭证空间的默认凭证

-(void)setDefaultCredential:(NSURLCredential*)credential forProtectionSpace:(NSURLProtectionSpace *)space;

当我们的凭证存储空间有变化时会发送FOUNDATION_EXPORTNSString *constNSURLCredentialStorageChangedNotification;通知。

好了说了这么多,然我们来继续看看挑战类吧NSURLAuthenticationChallenge,一个挑战类会包含:保护空间信息,凭证类(如果有的话),

这个类的函数如下:

//这个函数返回一个类NSURLProtectionSpace,类中描述服务器中希望的认证方式以及协议,主机端口号等信息。

  • (NSURLProtectionSpace*)protectionSpace;

//上次客户端接收挑战时所指定的认证的凭证,在没有指定时默认为nil

-(NSURLCredential*)proposedCredential;

//用户密码输入失败的重复次数。

-(NSInteger)previousFailureCount;

//也就是一个401响应头的详细信息。

-(NSURLResponse*)failureResponse;

//错误信息

-(NSError*)error;

//这个方法用来指定客户端如何来接收挑战。也就是客户端在处理willSendRequestForAuthenticationChallenge函数的最后必须指定接收挑战的方式。客户端可以调用sender中的协议指定的方法来执行接收挑战的方式。这个sender是系统实现的,客户端只要调用就可以了。

  • (id<NSURLAuthenticationChallengeSender>)sender;

//上面的sender是我们需要告诉服务器我们如何来接受挑战,这个协议实现了如下函数:

@protocol NSURLAuthenticationChallengeSender <NSObject>

//如果用户接收挑战则需要用户提供一个授权的凭证credential,用户需要建立这个凭证NSURLCredential对象。

-(void)useCredential:(NSURLCredential*)credential forAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge;

//告诉服务器我不管他要认证我继续处理不用输入认证用户和密码,如果调用了这个函数则会调用URLConnection的delegate的didReceiveResponse函数并且响应为401

-(void)continueWithoutCredentialForAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge;

//如果调用这个函数则我表示我不接收挑战了,这时候会调用URLConnection的delegate的didFailWithError函数表示错误了。

  • (void)cancelAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge;

@end

我们再来捋顺一下逻辑,当我们发送请求到服务端时,服务端需要我们挑战时会在客户端创建一个挑战对象NSURLAuthenticationChallenge,其中的保护空间NSURLProtectionSpace由服务器响应的信息来构建,而<NSURLAuthenticationChallengeSender>sender则内部构建,然后挑战对象会根据保护空间从凭证存储中获取对应的凭证对象,如果有凭证对象则会把凭证对象赋值给数据成员proposedCredential,建立挑战对象后判断当前有没有实现NSURLConnection的willSendRequestForAuthenticationChallenge的函数,如果没有实现则根据凭证对象来调用sender的接受挑战或者失败函数,而如果是我们实现了willSendRequestForAuthenticationChallenge就需要我们自己来处理如何接收挑战了,注意当我们调用sender的接收挑战函数,这个函数内部会把凭证和保护空间保存到凭证存储中去,以便下次继续使用(当然可以通过控制凭证的持久属性来决定是否保存)。因此有的时候我们可以在系统中预先植入一些特定服务器的保护空间和凭证,这样我们就不需要去处理willSendRequestForAuthenticationChallenge函数了,这种机制特别有效的用于处理webview来访问有些需要授权的或者https或者代理等等。

HTTP协议授权访问,布布扣,bubuko.com

时间: 2024-10-15 03:54:44

HTTP协议授权访问的相关文章

redis配置文件与未授权访问

redis配置文件与未授权访问 0x00 redis简述 REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统.Redis是一个开源的使用ANSI C语言编写.遵守BSD协议.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API.它通常被称为数据结构服务器,因为值(value)可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有

未授权访问总结学习

fastcgi(9000端口): 以下这段话摘自p神 Fastcgi其实是一个通信协议,和HTTP协议一样,都是进行数据交换的一个通道. HTTP协议是浏览器和服务器中间件进行数据交换的协议,浏览器将HTTP头和HTTP体用某个规则组装成数据包,以TCP的方式发送到服务器中间件,服务器中间件按照规则将数据包解码,并按要求拿到用户需要的数据,再以HTTP协议的规则打包返回给服务器. 类比HTTP协议来说,fastcgi协议则是服务器中间件和某个语言后端进行数据交换的协议.Fastcgi协议由多个r

http协议的访问之前端调优

http协议的访问之前端调优 大家伙估计都知道在浏览器的页面上面输入http://www.baidu.com:之后回车后就会进入百度的页面搜索自己想要的结果,但是不知道大家伙知道吗在你输入这个url路径之后,在这个过程当中经过了多少个过程?当然这里面的内容作为用户可以不用知道,只要得到自己想要的结果便可.但是作为运维人员这里面的门门道道必须知道并且有利与解决日常的错误. 今天就为大家带来有关于http这个过程经过了什么流程的介绍 http(超文本传输协议) 主要用于Web服务.通过计算机处理文本

Redis 未授权访问缺陷可轻易导致系统被黑【SSV-89715】

参考链接:https://www.sebug.net/vuldb/ssvid-89715 攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器. 环境: KaLi:192.168.2.162 CentOS:192.168.2.32 CentOS部署了redis数据库 步骤: 1.在Kali上生成密钥对: 命令:ssh-keygen -t rsa 2

Redis未授权访问漏洞

一.漏洞描述和危害 Redis因配置不当可以未授权访问,被攻击者恶意利用.攻击者无需认证访问到内部数据,可能导致敏感信息泄露,黑客也可以恶意执行flushall来清空所有数据. 攻击者可通过EVAL执行lua代码,或通过数据备份功能往磁盘写入后门文件,如果Redis以root身份运行,黑客可以给root账户写入SSH公钥文件,直接通过SSH登录受害服务器. 二.已确认被成功利用的软件及系统   对公网开放,且未启用认证的redis服务器. 三.建议修复方案 1.指定redis服务使用的网卡 (需

Redis未授权访问漏洞分析

catalog 1. Redis简介 2. 漏洞概述 3. 漏洞利用方式 4. 修复方式 1. Redis简介 Relevant Link: http://www.cnblogs.com/LittleHann/p/3901588.html 2. 漏洞概述 Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据.攻击者在未授权访

Redis未授权访问缺陷让服务器沦为肉鸡

阿里云的安全告警邮件内容: 在没有查到异常进程之前我是先把操作系统的带宽&端口用iptables 做了限制这样能保证我能远程操作服务器才能查找原因. 在各种netstat –ntlp  的查看下没有任何异常.在top 下查到了有异常进程还有些异常的这里就截图一个: 结果果断把进程给kill-9  了  没想到再去ps的时候又来了意思就是会自动启动它.这就让我想到了crond 这个自动任务果不其然/var/sprool/cron/root 这个文件被人做了手脚而且是二进制的,果断又给删除了,以为这

Redis 未授权访问缺陷可轻易导致系统被黑

Redis 未授权访问缺陷可轻易导致系统被黑 漏洞概要 Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据.攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器. 漏洞概述 Redis

Memcached 未授权访问漏洞及加固

memcached是一套分布式的高速缓存系统.它以Key-Value(键值对)形式将数据存储在内存中,这些数据通常是应用读取频繁的.正因为内存中数据的读取远远大于硬盘,因此可以用来加速应用的访问. 漏洞成因: 由于memcached安全设计缺陷,客户端连接memcached服务器后 无需认证就 可读取.修改服务器缓存内容. 漏洞影响: 除memcached中数据可被直接读取泄漏和恶意修改外,由于memcached中的数据像正常网站用户访问提交变量一样会被后端代码处理,当处理代码存在缺陷时会再次导