网站导航网学 原创论文 原创专题 网站设计 最新系统 原创论文 论文降重 发表论文 论文发表 UI设计定制 论文答辩PPT格式排版 期刊发表 论文专题
返回网学首页
网学原创论文
最新论文 推荐专题 热门论文 论文专题
当前位置: 网学 > 交易代码 > 课程设计 > 正文

C#安全Cookie的设计开发

论文降重修改服务、格式排版等 获取论文 论文降重及排版 论文发表 相关服务
C#安全Cookie的设计开发摘要 vAbstract vi前言 vii第一章  概  述 11.1 背景知识 11.2 Cookie应用中存在问题 21.3 解决方案 21.4 安全Cookie设计的技术路线及预期目标 4第二章 Cookie技术分析 52.1Cookie技术概述 52.2 Cookie技术 62.2.1 Cookie运行机制 62.2.2 Cookie的结构 72.3 加密技术 82.3.1 MD5加密算法 92.3.2AES加密算法 92.3.3 SHA1加密算法 102.3.4 DES加密算法 102.3.5 TripleDES加密算法 112.3.6 算法对比 122.4 小结 12第三章 系统模型设计 133.1 系统模型 133.2 模型设计 143.3 设计开发的流程及方法 183.4  小结 19第四章 系统实现 204.1 设计环境介绍 204.2 模型设计的实现 204.2.1系统配置 204.2.2模型实现 214.3 程序设计开发说明 244.4 调试经验 284.5 小结 29第五章 系统运行结果和分析 305.1 实现结果分析 305.1.1常规Cookie模型实现的分析 305.1.2加密Cookie模型实现效果 325.1.3MAC/IP绑定加密Cookie模型分析 365.2 结果比较分析 395.3 小结 40第六章 总结与收获 41谢辞 42参考文献 43附录 45附录 1 程序代码 45附录 2  英语论文与翻译 104
 

C#安全Cookie的设计开发
摘要
Cookie是一小段文本信息,伴随着用户请求和页面在 Web 服务器和浏览器之间传递。Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。服务器可以利用Cookie包含信息的任意性来筛选并经常性维护这些信息,以判断在HTTP传输中的状态。使用 Cookie 能够达到多种目的,所有这些目的都是为了帮助网站记住用户。
Cookie技术的应用,给网站带来了更多的功能,也给用户带来了极大的方便和个性化的体验,然而, 由于Cookie 以明文形式在浏览器和服务器间发送,任何可以截获 Web 通信的人都可以读取 Cookie、设置 Cookie 属性,而且Cookie信息也可以从用户的电脑上被盗走,所以不正当地利用此技术会造成用户信息的安全问题。
对于上述安全问题,本设计中采用以下方法确保Cookie的安全,首先是在Cookie内容中加入MAC/IP鉴别信息来防止Cookie被盗用,然后使用AES/SHA1算法来加密Cookie内容来防止Cookie内容泄露。经实际测试验证,该方法有效的保证了Cookie的安全。
关键字:Cookie,隐私,安全,加密解密
Abstract
Cookie is a short text message, along with the request of users and pages between the Web server and browser. Cookie contains the information that applications can read whenever user accesses the Web sites. Web server can use the trait of Cookie that it can carry any information to filter and regularly maintain the information, so the state of the HTTP transmission can be determined. Cookie can be used to achieve a variety of purposes, all of these are designed to help Web sites to remember user.
The applications of the Cookie technology make the site more functional, and they also bring great convenience and personalized experience to users, information can also be stolen from the user's computer, so the improper use of this technology will cause personal information security issues.
Towards the security issues of Cookie technology that mentioned above, this design use the following methods to ensure the safety of Cookie. First add a MAC / IP identification information to the Cookie content to prevent unauthorized use, and then use the AES/SHA1 algorithm to encrypt the Cookie content to prevent leakage. With the practical test verification, this method is effective in ensuring the security of Cookie.
Keywords: Cookie, privacy, security, encryption and decryption
 
C#安全Cookie的设计开发

前言
HTTP 协议其轻巧通用、面向对象的特点使它适合在分布式协作环境下使用。HTTP 协议是一种无状态协议,当一个客户向服务器发出请求,然后服务器返回响应,请求完成后,连接就被关闭了。服务器不再保留有关连接的信息,所以当下一次请求并连接时,服务器无法判断本次连接和以前的连接是否同一个用户[1]。所以HTTP的无状态性不能满足某些应用的需求,给Web操作带来种种不便。在此前提下,提出了HTTP的状态管理机制— Cookie机制。现在,Cookie技术已经被广泛的应用与各种网站和个人桌面操作系统,绝大多数的浏览器都支持Cookie技术,或者至少兼容Cookie技术的使用。另一方面,自从这项技术诞生的那天起,它就饱受争议,因为不正当地利用此技术会造成用户信息的安全问题。由于大多数用户对它的功能、使用方法还不十分熟悉,往往在没有任何防备的情况下,被那些居心不良的网站或个人盗走了重要的私人信息(包括计算机的型号配置、个人的银行帐号密码等),造成重大损失[2]。
本设计的目标就是使用强壮合理的加密手段对网站的Cookie信息进行加密处理,杜绝Cookie信息泄露用户隐私,同时使用一定的身份鉴别技术来保证Cookie不会被盗用,从而做到了Cookie信息的安全处理。
本设计在实际应用中有非常重要的价值,如今,网站使用Cookie技术可以记住用户的个性化设置,给用户带来更好的体验;广告商通过Cookie技术可以有针对性的对用户投放广告,提高广告效益,同时可以避免投放不合用户口味的广告造成用户的反感;Cookie技术在网站的身份认证系统中,特别是单点登陆系统中可以得到广泛的应用;在网上购物系统中,通过Cookie技术可以很轻松的实现购物车功能,等等。上述应用中利用本设计中的安全Cookie技术可以保证用户的隐私不会被第三方得知,特别是在身份验证系统中,安全的Cookie设计可以使得网站开发者放心的使用Cookie技术来登陆验证,有效的降低服务器资源消耗,提高效率。
第一章  概  述
1.1 背景知识
HTTP 协议其轻巧通用、面向对象的特点使它适合在分布式协作环境下使用。HTTP协议是针对相互间无连接的事物进行处理,是一种无状态、无连接的协议,不能在服务器上保持一次会话的持续状态信息。但是HTTP的无状态性不能满足某些应用的需求,给Web操作带来种种不便。
在此前提下,提出了HTTP的状态管理机制— Cookie机制。Cookie,有时也用其复数形式Cookies,定义于RFC2109。它是网景公司的前雇员Lou Montulli在1993年3月的发明[12]。在WEB技术发展史上,Cookie技术的出现是一个重大的变革。最先是Netscape1993年在它的Netscape Navigator浏览器中引入了Cookie技术,从那时起,World Wide Web 协会就开始支持Cookie标准。以后又经过微软的大力推广(因为微软的IIS Web服务器所采用的ASP技术很大程度的使用了Cookie技术),即在微软的Internet Explorer浏览器中完全支持Cookie技术[15]。到现在,绝大多数的浏览器都支持Cookie技术,或者至少兼容Cookie技术的使用。
按照Netscape官方文档中的定义,Cookie是在HTTP协议下,服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由Web服务器保存在用户浏览器上的小文本文件,包含每次用户访问站点时Web应用程序都可以读取的信息。服务器可以利用Cookie包含信息的任意性来筛选并经常性维护这些信息,以判断在HTTP传输中的状态。无论何时用户链接到服务器,Web站点都可以访问Cookie信息[4]。
一般来说,Cookie通过HTTP Headers从服务器端返回到浏览器上。首先,服务器端在响应中利用Set-Cookie header来创建一个Cookie ,然后,浏览器在它的请求中通过Cookie header包含这个已经创建的Cookie,并且反它返回至服务器,从而完成浏览器的论证[5]。目前有些Cookie 是临时的,另一些则是持续的。临时的Cookie只在浏览器上保存一段规定的时间,一旦超过规定的时间该Cookie就会被系统清除。
1.2 Cookie应用中存在问题
现在,Cookie技术已经被广泛的应用与各种网站和个人桌面操作系统,绝大多数的浏览器都支持Cookie技术,或者至少兼容Cookie技术的使用。另一方面,自从这项技术诞生的那天起,它就饱受争议,因为不正当地利用此技术会造成用户信息的安全问题[6]。由于大多数用户对它的功能、使用方法还不十分熟悉,往往在没有任何防备的情况下,被那些居心不良的网站或个人盗走了重要的私人信息(包括计算机的型号配置、个人的银行帐号密码等),造成重大损失。因为Cookie是以明文的形式保存与传输的,所以存在着一定的危险,通常存在着三种情况的安全攻击[14]:
网络攻击:Cookie是以明文的形式在网络中进行传输的,如果没有安全的信道,该信息在传输过程中就有可能遭到不法之徒的拦截,窃取,篡改,冒用等。
客户端攻击:由于Cookie是以明文的形式保存在客户端的硬盘上的,该信息就有可能被非法用户拷贝,对信息进行冒用,修改等。
服务器端攻击:非法攻击者破坏正常服务器的运行,并冒用该服务器的地址及域名,当用户登录该网站时,非法攻击者就可以获取该用户的信息,并根据获取的信息登录,进行非法操作。
可见,如果不对Cookie的使用采用一些对抗攻击的技术手段,无论对于网站还是对于用户来说,都是非常危险的。因此需要采取措施来对Cookie信息进行处理。
1.3 解决方案
鉴于1.2节中提到的Cookie安全问题,必须采取相应的措施来保证Cookie使用中的安全。安全的Cookie必须具备以下三个方面的特性:
l        机密性
Cookie通常含有用户身份鉴别信息和用户个人资料,因此要求必须确保这些信息的机密性 Cookie信息泄露有两个主要途径:一是在传输途中被截获;二是存储于用户设备时被窃取。[16]
l        完整性
为防止攻击者使用特殊标记向Cookie写入恶意可执行代码,要求必须确保Cookie的完整性 当Cookie被用于用户身份鉴别时,如果Cookie内容被篡改,那么鉴别就会失败。攻击者可以篡改合法用户Cookie内容,阻碍该用户访问特定Web站点。Cookie中域名项和路径项也很重要。如果攻击者篡改这两项,Cookie就会被送至攻击者手中。[16]
l        可鉴别性
将Cookie加密可以抵御非法篡改。但是,攻击者通过向Web站点提交从合法用户处窃取的Cookie,仍然可以假冒该合法用户。因此,要求必须能够校验提供Cookie的实体确是该Cookie合法所有者。[16]
所以,必须针对以上所列出的安全Cookie的三个特性采取相应的措施,才能保证Cookie的安全。本设计的解决方案正是针对此三种特性制定了相应的解决方案:
l        对于“机密性”的解决方案
使用强壮的加密算法对Cookie信息进行加密,可以防止Cookie中的敏感信息的泄露,只有拥有密钥的服务器才可以解密和识别该信息。
l        对于“完整性”的解决方案
使用有效的算法生成MAC(message authentication code)对Cookie信息进行签名。Web服务器读取Cookie后对Cookie进行签名校验,若Cookie被更改了,校验必定无法通过,从而有效的防止了Cookie的伪造和篡改。
l        对于“可鉴别性”的解决方案
在目前的IPV4网络中,将客户端MAC地址或者IP地址加入到Cookie信息中,并加密。服务器读取Cookie后,解密出其中的附加MAC/IP信息,若与客户端当前MAC或IP相符,则认为该Cookie来源合法。在IPV6网络中,将客户端MAC和IP地址都加入到Cookie信息中,并加密。服务器读取Cookie后,解密出其中的MAC和IP信息,若与当前请求的客户端MAC和IP 相符,则认为该Cookie来源合法。
 
C#安全Cookie的设计开发
1.4 安全Cookie设计的技术路线及预期目标
围绕1.3节中提出的解决方案,本设计的技术路线已经很明确。对于Cookie的“机密性”,需要选择一种加密算法,经过查阅文献资料来分析和对比各种加密解密算法,AES算法以其高度的安全性和优异的性能得到了采纳;同时,在加密算法中需要采用合理的电子签名算法来实现Cookie的“完整性”,经过对比,最终采纳了SHA1算法;在“可鉴别性”上,开发出MAC/IP绑定Cookie的鉴别方法来保证Cookie不被盗用。加密和电子签名使用ASP.NET的加密Cookie方法同时实现,MAC地址是调用Win32的API使用ARP协议获取。
根据以上提出的设计思想,可以建立完整的系统模型。作为对比验证,本设计分别针对1.3节中确定的安全Cookie的三种特性建立了对比模型,分别为“明文Cookie模型”、“加密Cookie模型”、“MAC/IP地址绑定加密Cookie模型”。在“明文Cookie模型”中,用户登陆成功后,用户名被保存在Cookie中;在“加密Cookie模型”中,用户登陆成功后,生成身份验证票据,加密后保存在Cookie中;在“MAC/IP地址绑定加密Cookie模型”中,用户登陆成功后,获取客户端MAC/IP地址作为身份验证票据的自定义字段,生成身份验证票据并加密,存入Cookie中。经过对比测试,可确定“MAC/IP地址绑定加密Cookie模型”为安全Cookie设计。
确定了系统模型,使用Microsoft Visual Studio 2005使用C#来实际开发各个模型的ASP.NET网站模型。调试程序时,为了模拟真实的网络环境,需要使用三台互联的计算机,一台作为Web服务器,另外二台作为工作站。测试时需要使用一个Cookie修改工具和一个Cookie欺骗工具来对所设计的模型进行安全性测试。
按照以上列出的技术路线实施之后,可以充分证明“MAC/IP地址绑定加密Cookie模型”的设计实现了安全Cookie。
本设计的预期目标是:通过本方案生成的Cookie信息在没有密钥的情况下几乎是不可能取得其信息的;即使系统的Cookie被非法盗取,使用该Cookie在其它电脑上登陆本系统,服务器程序可以识别,并拒绝该Cookie。
第二章 Cookie技术分析
2.1Cookie技术概述
在WEB技术发展史上,Cookie技术的出现是一个重大的变革。最先是Netscape在它的Netscape Navigator浏览器中引入了Cookie技术,从那时起,World Wide Web 协会就开始支持Cookie标准。以后又经过微软的大力推广(因为微软的IIS Web服务器所采用的ASP技术很大程度的使用了Cookie技术),即在微软的Internet Explorer浏览器中完全支持Cookie技术[15]。到现在,绝大多数的浏览器都支持Cookie技术,或者至少兼容Cookie技术的使用。
按照Netscape官方文档中的定义,Cookie是在HTTP协议下,服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由Web服务器保存在用户浏览器上的小文本文件,它可以包含有关用户的信息(如身份识别号码、密码、用户在Web站点购物的方式或用户访问该站点的次数)。无论何时用户链接到服务器,Web站点都可以访问Cookie信息。[15]
一般来说,Cookie通过HTTP Headers从服务器端返回到浏览器上。首先,服务器端在响应中利用Set-Cookie header来创建一个Cookie ,然后,浏览器在它的请求中通过Cookie header包含这个已经创建的Cookie,并且返回至服务器,从而完成浏览器的论证。目前有些Cookie 是临时的,另一些则是持续的。临时的Cookie只在浏览器上保存一段规定的时间,一旦超过规定的时间该Cookie就会被系统清除。[3]
Cookie技术的应用,给网站带来了更多的功能,也给用户带来了极大的方便和个性化的体验,然而, 由于Cookie 以明文形式在浏览器和服务器间发送,任何可以截获 Web 通信的人都可以读取 Cookie、设置 Cookie 属性,而且Cookie信息也可以从用户的电脑上被盗走,所以不正当地利用此技术会造成用户信息的安全问题。因此,要保证Cookie使用中的安全,必须对Cookie信息进行加密处理,并且加入电子签名和合法性鉴别。[6]
2.2        Cookie技术
2.2.1 Cookie运行机制
Cookie运行机制如下图2.1-1[1]

图2.1-1 Cookie的运行机制若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
1客户方向服务器发起一个请求;
2服务器接收到请求后产生一个Set-Cookie 报头放在HTTP报文中一起发给客户方发起一次会话;
3客户端收到该应答后将Set-Cookie 中的内容取出形成一个TXT文件;
4当客户方再提出一个请求后将Cookie.txt中的内容读出产生Cookie报头放在HTTP请求报文中发给服务器
5服务器接收到包含Cookie报头的请求检索其Cookie中与用户有关的信息生成一个客户方所请示的页面应答传递给客户方这便是HTTP协议中的Cookie机制运行的基本过程以此来解决HTTP协议无连接无状态的问题
2.2.2 Cookie的结构
Cookie的结构如图2.2.2-1[3]

图2.2.2-1 Cookie的结构
下面对Cookie的6个属性分别详述:
Cookies Name 必需属性, 指明了Cookie 的名字, 由一系列字符(不包括括号、逗号和空格) 组成;
Cookies Value  Cookie的值,Web服务器存储在Cookie中的信息;
Domain    可选, 指明了Cookie的有效域范围, 默认为产生Cookie的服务器的名字;
Path   可选,指明了Cookie 在有效域中的有效路径, 在有效路径外的网页不可以读写Cookie,默认为产生此Cookie的文档的URL;
Secure 可选,如果标记一个Cookie为安全的, 那么仅当客户端与服务器的对话通道是安全的(如HTTP over SSL),Cookie才会被传送.
Expire Date 可选, 指明了Cookie的存活期,一旦过期, Cookie将不再有效.expires为关键字,date由服务器指明,如果不指明, 系统默认Cookie将在用户会话结束后自动过期.
2.3           加密技术
加密算法可分为可逆加密算法和不可逆加密算法。其中可逆算法按照密钥类型不同可分为两类:对称加密算法(秘密密钥加密)和非对称加密算法(公开密钥加密)
 
C#安全Cookie的设计开发
对称密钥加密系统是加密和解密均采用同一把秘密密钥,而且通信双方都必须获得这把密钥,并保持密钥的秘密,常见的有DES、3DES、AES算法。非对称密钥加密系统采用的加密密钥(公钥)和解密密钥(私钥)是不同的,常见的有RSA、DSA、ECC加密算法。不可逆算法(散列算法),散列是信息的提炼,通常其长度要比信息小得多,且为一个固定长度[10]。加密性强的散列一定是不可逆的,这就意味着通过散列结果,无法推出任何部分的原始信息。任何输入信息的变化,哪怕仅一位,都将导致散列结果的明显变化,这称之为雪崩效应[17]。散列还应该是防冲突的,即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改,常见的有MD5、SHA1算法。
本设计在ASP.NET2.0中使用forms authentication Cookie来说明如何设计一个安全的Cookie。首先创建一个序列化的forms authentication ticket:即创建此对象为一个字节数组(byte array);然后创建forms authentication ticket的签名。machineKey中的validation和alidationKey属性所设置了生成签名的算法[19]。用此算法计算上面序列化的bytearray,生成MAC(message authentication code); 最后加密forms authentication ticket,同时创建另外一个序列化的对象,此对象经过加密算法加密。这个加密算法也可在machineKey中的decryption和decryptionKey的属性中获得[19]。
machineKey中加密方法(validation)可以选择的有:MD5算法、AES算法、SHA1算法、TripleDES(3DES)算法。解密方法(decryption)可以选择的有:DES算法、TripleDES(3DES)算法、AES算法。[18]下面分别对这五种算法进行分析。
 
2.3.1   MD5加密算法
MD5 - Message Digest 5 (MD5) 是一种用于产生数字签名的单向散列算法,在1991年由MIT Laboratory for Computer Science(IT计算机科学实验室)和RSA Data Security Inc(RSA数据安全公司)的Ronald L. Rivest教授开发出来,经由MD2、MD3和MD4发展而来[19]。MD5以512位分组来处理输入的信息,且每一分组又被划分为16个32位子分组,经过了一系列的处理后,算法的输出由四个32位分组组成,将这四个32位分组级联后将生成一个128位散列值。MD5 可以提供一些保护,以防止遭受计算机病毒和某些程序(看上去像是无害的应用程序,而实际上具有破坏性)的攻击。MD5算法作用是让大容量信息在用数字签名软件签私人密钥前被"压缩"成一种保密的格式,将一个任意长度的“字节串”通过一个不可逆的字符串变换算法变换成一个128bit的大整数,即使看到源程序和算法描述,也无法将一个MD5的值变换回原始的字符串,从数学原理上说,是因为原始的字符串有无穷多个。[16]
2.3.2AES加密算法
2000年10月,NIST(美国国家标准和技术协会)宣布通过从15种侯选算法中选出的一项新的密钥加密标准。Rijndael被选中成为将来的AES。 Rijndael是在 1999 年下半年,由研究员 Joan Daemen 和 Vincent Rijmen 创建的。AES 正日益成为加密各种形式的电子数据的实际标准。美国标准与技术研究院 (NIST) 于 2002 年 5 月 26 日制定了新的高级加密标准 (AES) 规范。[10]
AES 算法基于排列和置换运算。排列是对数据重新进行安排,置换是将一个数据单元替换为另一个。AES使用几种不同的方法来执行排列和置换运算。
AES 是一个迭代的、对称密钥分组的密码,可使用128、192 和256位密钥,并且用128位(16字节)分组加密解密数据。与公共密钥密码使用密钥对不同,对称密钥密码使用相同的密钥加密解密数据。返回的加密数据的位数与输入数据相同。迭代加密使用一个循环结构,在该循环中重复置换和替换输入数据。[16]
 
2.3.3   SHA1加密算法
SHA-1是一种数据加密算法,该算法的思想是接收一段明文,然后以一种不可逆的方式将它转换成一段(通常更小)密文,也可以简单的理解为取一串输入码(称为预映射或信息),并把它们转化为长度较短、位数固定的输出序列即散列值(也称为信息摘要或信息认证代码)的过程。[10]
单向散列函数的安全性在于其产生散列值的操作过程具有较强的单向性。如果在输入序列中嵌入密码,那么任何人在不知道密码的情况下都不能产生正确的散列值,从而保证了其安全性。SHA将输入流按照每块512位(64个字节)进行分块,并产生20个字节的被称为信息认证代码或信息摘要的输出。[16]
该算法输入报文的最大长度不超过264位,产生的输出是一个160位的报文摘要。输入是按512 位的分组进行处理的。SHA-1是不可逆的、防冲突,并具有良好的雪崩效应。
通过散列算法可实现数字签名实现,数字签名的原理是将要传送的明文通过一种函数运算(Hash)转换成报文摘要(不同的明文对应不同的报文摘要),报文摘要加密后与明文一起传送给接受方,接受方将接受的明文产生新的报文摘要与发送方的发来报文摘要解密比较,比较结果一致表示明文未被改动,如果不一致表示明文已被篡改。[17]
2.3.4   DES加密算法
DES是一个分组加密算法,以64位为分组对数据加密。同时DES也是一个对称算法:加密和解密用的是同一个算法。它的密钥长度是56位(因为每个第8位都用作奇偶校验),密钥可以是任意的56位数,而且可以任意时候改变。其中有极少量的数被认为是弱密钥,但是很容易避开他们。所以保密性依赖于密钥。[10]
DES对64(bit)位的明文分组M进行操作,M经过一个初始置换IP置换成m0,将m0明文分成左半部分和右半部分m0=(L0,R0),各32位长。然后进行16轮完全相同的运算,这些运算被称为函数f,在运算过程中数据与密钥结合。经过16轮后,左,右半部分合在一起经过一个末置换,这样就完成了。[16]
在每一轮中,密钥位移位,然后再从密钥的56位中选出48位。通过一个扩展置换将数据的右半部分扩展成48位,并通过一个异或操作替代成新的32位数据,在将其置换一次。这四步运算构成了函数f。然后,通过另一个异或运算,函数f的输出与左半部分结合,其结果成为新的右半部分,原来的右半部分成为新的左半部分。将该操作重复16次,就实现了。[16]
DES加密和解密唯一的不同是密钥的次序相反。如果各轮加密密钥分别是K1,K2,K3….K16那么解密密钥就是K16,K15,K14…K1。
2.3.5   TripleDES加密算法
Triple DES(即3DES)是DES向AES过渡的加密算法(1999年,NIST将3DES指定为过渡的加密标准),是DES的一个更安全的变形。它以DES为基本模块,通过组合分组方法设计出分组加密算法,其具体实现如下:
设Ek()和Dk()代表DES算法的加密和解密过程,K代表DES算法使用的密钥,P代表明文,C代表密表,这样
3DES加密过程为:C=Ek3(Dk2(Ek1(P)))
3DES解密过程为:P=Dk1((EK2(Dk3(C)))
K1、K2、K3决定了算法的安全性,若三个密钥互不相同,本质上就相当于用一个长为168位的密钥进行加密。多年来,它在对付强力攻击方面是比较安全的。若数据对安全性要求不那么高,K1可以等于K3。在这种情况下,密钥的有效长度为112位。[16]
 

C#安全Cookie的设计开发
2.3.6   算法对比
以上算法是目前常用的加密算法,表2.3.7-1对这些算法进行了对比。
表2.3.7-1 常用加密算法比较





名称

算法类型

密钥长度

摘要长度

速度

资源消耗

安全性


MD5

散列分组



128





易受攻击,已有破解方法


SHA1

散列分组



160





不易受攻击,破解难度大


AES

对称分组

128、192、256位







安全性高,尚未被破解


DES

对称分组

56位







安全性中、破解难度大


3DES

对称分组

112、168位







安全性高
 
由上表可以看出,对于MD5和SHA1这2中签名算法,前者在速度和资源消耗上占优势,但是相对于SHA1算法而言,安全性要低,容易受到攻击;后者虽然在效率上要差,但是考虑到Cookie信息的数据量并不多,对于目前的计算处理速度来说,不构成瓶颈,因此,选用SHA1算法进行电子签名比较合理。对于Cookie信息的加密采用的算法,可以明显看出AES算法无论在算法的效率还是安全级别都比DES和3DES要高,毫无疑问的选择AES算法作为Cookie的信息加密算法。
2.4 小结
根据以上对Cookie结构的分析和加密算法的对比,可以清楚的看到,SHA1算法在安全性方面要比MD5高出很多,性能上的损失在当前计算机处理水平上可以忽略,因此确定采用SHA1算法对Cookie信息进行签名;AES算法无论在算法的效率还是安全级别都比DES和3DES要高,因此确定对Cookie中的数据部分采用AES算法。
确定了本次设计的技术方案和设计路线,据此便可以设计出系统的模型。
第三章 系统模型设计
3.1 系统模型
本系统模型分为二个部分,Web服务器产生Cookie的模型(见图3.1-1)和Web服务器验证Cookie的模型(见图3.1-2)
图3.1-1 Web服务器生成Cookie模型
该模型展示了Web服务器产生Cookie信息的过程。原始信息中加入客户端特征信息(本设计中为客户端MAC地址或者IP地址),经过SHA1数字签名后使用AES加密算法加密,经过以上过程处理后的信息被加入到HTTP报文中发送至客户端浏览器。待下次客户端请求服务器时,发送该Cookie给服务器,服务器对其进行验证。如下图3.1-2所示。若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
图3.1-2 Cookie验证模型
该模型展示了客户端浏览器请求Web网站时,Web服务器对Cookie的验证过程。Web服务器获取HTTP头中的Cookie信息后,使用密钥将其内容解密,然后提取其中的签名信息,使用签名算法重新计算Cookie签名,若签名不符则拒绝该Cookie的业务操作,若签名通过,则比较Cookie中的客户端特征信息,若特征信息不符,则拒绝该Cookie的业务操作,若特征信息符合,则认为该Cookie合法,运行其进行业务操作。
通过以上对本设计的业务流程的分析,可以对系统的模型进行详细的设计。
3.2 模型设计
本设计中使用了3套Cookie模型来说明安全Cookie的设计,分别为:明文Cookie模型(图3.2-1)、加密Cookie模型(图3.2-2)、MAC地址/IP地址绑定的加密Cookie模型(图3.2-3)。
图3.2-1 明文Cookie模型
明文Cookie模型中,用户通过登陆页面输入用户名和密码登陆,验证失败重返登陆页,验证成功后将用户名放入Cookie信息中,然后服务器通过HTTP报文将Cookie发送至客户端浏览器,浏览器下次请求Web服务器时,发送Cookie至Web服务器,Web服务器读取Cookie,确认用户身份。
 
C#安全Cookie的设计开发
图3.2-2 加密Cookie模型
加密Cookie模型中,用户通过登陆页面登陆系统,若用户名密码无效,返回登陆页,若用户名密码正确,则生成用户的身份验证票据,并使用SHA1算法对票据签名,接着使用AES算法对票据加密,最后将密文作为Cookie通过HTTP头发送至客户端浏览器。浏览器下次进入网站时,将Cookie发送至Web服务器,Web服务器读取该Cookie,使用AES密钥解密该Cookie密文,然后对Cookie进行签名校验,若校验通过,即可确认用户身份,否则,返回登陆页面。
若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
图3.2-3 MAC地址/IP地址绑定加密Cookie模型
MAC地址/IP地址绑定加密Cookie模型中,用户通过登陆页面登陆系统,若用户名密码无效,返回登陆页,若用户名密码正确,则使用客户端MAC/IP地址结合用户信息生成用户的身份验证票据,然后使用SHA1算法对票据签名,并使用AES算法对票据加密,最后将密文作为Cookie通过HTTP头发送至客户端浏览器。浏览器下次进入网站时,将Cookie发送至Web服务器,Web服务器读取该Cookie,使用AES密钥解密该Cookie密文,然后对Cookie进行签名校验,若校验失败,返回登陆页面,否则,提取Cookie中的MAC/IP地址与当前获得的客户端MAC/IP地址对比,若MAC/IP地址相符,即可确认用户身份,否则,返回登陆页面。
经过以上对系统模型的建立以及分析,可以顺利的进行模型开发,开发的流程及方法已经很明确,在下一节将重点介绍。
3.3 设计开发的流程及方法
本次设计主要有六个流程来实现对安全Cookie的实现和验证过程[4,7,11]。
1  建立存储用户信息的SQL 数据库(aspnetdb),以在网站中验证用户身份;
2  设计ASP.NET网站的基本框架,包括一个登陆界面(Login.aspx)和一个登陆后显示Cookie信息的页面(Default.aspx),并对页面外观进行适当的美化和修饰;
3  设计程序代码,建立一个HttpCookie对象来进行身份验证,并以明文形式将其存储在客户端Cookie中;
4  改进以上程序中使用明文Cookie方法,使用ASP.NET的身份验证票据(FormsAuthenticationTicket)进行身份验证,使用FormsAuthentication的Encrypt方法来加密身份验证票据,该方法实现了2个功能,其一是使用SHA1算法对票据进行电子签名,防止票据信息被修改;其二是使用AES加密算法对票据进行加密,防止票据信息泄露;
5  继续改进以上程序中的Cookie信息,在验证票据中加入客户端的MAC地址,若无法获取MAC地址,则取IP地址替代。这样,在Web服务器验证Cookie时,对Cookie中的MAC/IP地址进行判断,从而来防止Cookie被冒用。
6  分别对以上3种方法生产的Cookie进行验证,证明第三种方法产生的Cookie具有很高的安全性。
按照上述流程和方法设计系统模型,并对模型理论进行实际验证之后,可以确定最终模型,证明了安全Cookie的设计是可靠的,在下一节中将给出结论。
3.4  小结
本设计从三个方面来考虑了Cookie的安全性,分别是保密性、完整性、可鉴别性。在保密性方面,本设计在程序中采用了AES加密算法来确保Cookie信息几乎不可能破解;完整性方面,采用SHA1签名算法来保证Cookie信息没有被篡改,在目前的技术水平下,这点是可以保证的;在可鉴别性方面,需要在Cookie中加入客户端的特征信息,在客户端每次请求Web页时,服务器就从Cookie中提取该特征信息来对请求页面的客户端身份进行鉴别,本设计中采用的是MAC地址或者IP地址其中之一来鉴别。由于考虑到IPV4网络中,IP地址大多都不是固定的,而只有MAC地址是固定的,所以程序中优先采用MAC地址验证,在无法取得MAC地址的情况下,采取IP地址验证的方法。当然,此方法存在缺陷,IP地址变化之后,Cookie会被拒绝,但是在能够获取MAC地址的情况下就不会存在这个问题了,因此,这种方法虽然降低了适用性,但是安全性得到了大幅度的提高。在未来的IPV6网络中[20],可以采用MAC地址和IP地址双重验证的方法来解决IP变更的问题,进一步提高安全性。
由此,系统模型可以确定,即采用“MAC/IP地址绑定加密Cookie模型”为安全Cookie设计模型。本设计采用ASP.NET开发,有广泛的适用性。在下一章节中具体实施。
 
C#安全Cookie的设计开发
第四章 系统实现
4.1 设计环境介绍
1、系统环境:Windows Server 2003、.Net Framework 2.0 、Microsoft SQL Server 2005
2、开发环境:Microsoft Visual Studio 2005、ASP.NET2.0、C#语言
3、网络环境:3台PC通过TP-LINK R402M SOHO宽带路由器组成局域网。其中一台作为Web服务器,另外二台作为工作站。
4、测试工具: IECookiesView V1.71、Cookies & Inject Browser
4.2 模型设计的实现
4.2.1系统配置
网络配置[13]:3台计算机通过宽带路由器组成局域网,其中一台作为服务器,提供Web服务、数据库服务、DNS服务;另外二台作为工作站,用来访问Web服务器。服务器和工作站均在192.168.1.0/255.255.255.0网段中,其中网关的IP是192.168.1.1/255.255.255.0,服务器IP是192.168.1.2/255.255.255.0,工作站一IP是192.168.1.3/255.255.255.0,工作站二的IP是192.168.1.4/255.255.255.0。3台计算机的DNS服务器均设置成192.168.1.2。
DNS服务配置[21]:作为实验环境中,DNS服务器(192.168.1.2/24)新建一个正向主要区域,域名为d;在d域中新建3个主机名,分别为Cookie1、Cookie2、Cookie3,指向的IP均为192.168.1.2。
IIS服务配置[21]:打开服务器的Internet信息服务(IIS)管理器,新建3个网站,对应的设置参数如表4.2-1所示。
 
 
表4.2-1 IIS网站配置参数





网站名称

IP地址

端口

主机头

主目录

对应的系统


演示网站一

192.168.1.2

80

Cookie1.d

E:\Cookie1

明文Cookie系统


演示网站二

192.168.1.2

80

Cookie2.d

E:\Cookie2

加密Cookie系统


演示网站三

192.168.1.2

80

Cookie3.d

E:\Cookie3

MAC/IP绑定加密Cookie系统
SQL Server 2005服务配置[22]:SQL Server 2005安装完毕之后,设置的超级管理员用户名为sa,密码为sa_123456。然后使用ASP.NET SQL Server安装向导(路径:C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe)来创建一个默认成员数据库。
完成上述系统配置,本设计的开发前准备工作已经全部完成,下面具体实施本系统的开发调试。
4.2.2模型实现
按照上节中所述的配置方法完成之后,使用Microsoft Visual Studio 2005新建一个ASP.NET网站,然后依次展开菜单[网站]-[ASP.NET网站配置],打开ASP.NET网站配置工具,点击“安全”链接,选择身份验证类型为“通过Internet”即Form窗体验证,添加新用户:用户名为dsz,密码为dsz_123456。配置完成之后关闭ASP.NET网站管理工具。然后分别实现系统模型。
Ø        明文Cookie模型的设计实现[4,5,7]:
打开Microsoft Visual Studio 2005打开一个ASP.NET网站,网站位置为“本地IIS”中的“演示网站一”,新建登陆页面“Login.aspx”存放于网站根目录,Login.aspx窗体中放置登陆框,用户可以在这里输入用户名和密码登陆系统。新建页面Default.aspx,此页面限制只有注册用户登陆之后才可以查看,页面中显示从Cookie中读取的信息。编辑Web.config文件,添加数据库连接,连接SQL Server中的aspnetdb数据库来提供用户。
对该模型安全性的验证方法为:从工作站一打开网站http://Cookie1.d,使用正确的用户名“dsz”和密码“dsz_123456”登陆,并选中“下次自动登陆”复选框,这样Cookie就被保存在“C:\Documents and Settings\用户名的文件夹\Cookies”中,用记事本将此文件打开administrator@Cookie1.d.txt这个文件,可以看到用户名被明文保存在其中,使用IECookiesView对此Cookie文件进行修改或者在工作站二中使用Cookies & Inject Browser工具将Cookie值提交到网站http://Cookie1.d,发现网站并没有要求登陆就直接打开了“Default.aspx”页面,因此,这种Cookie设计的方法是不安全的。
Ø        加密Cookie模型的设计实现[4,5,6,7]:
打开Microsoft Visual Studio 2005打开一个ASP.NET网站,网站位置为“本地IIS”中的“演示网站二”,新建登陆页面“Login.aspx”存放于网站根目录,Login.aspx窗体中放置登陆框,用户可以在这里输入用户名和密码登陆系统。新建页面Default.aspx,此页面限制只有注册用户登陆之后才可以查看,页面中显示从Cookie中读取的密文信息以及从密文中解密出来的明文信息,用以对比加密效果。编辑Web.config文件,加密解密方法以及加密解密的密钥,Form身份验证的各项参数(包括Cookie名,Cookie模式、Cookie有效期、Cookie路径等),添加数据库连接来连接SQL Server中的aspnetdb数据库来提供用户。
对该模型安全性的验证方法为:从工作站一打开网站http://Cookie2.d,使用正确的用户名“dsz”和密码“dsz_123456”登陆,并选中“下次自动登陆”复选框,这样Cookie就被保存在“C:\Documents and Settings\用户名的文件夹\Cookies”中,用记事本将此文件打开administrator@Cookie2.d.txt这个文件,可以发现Cookie文件中的内容是一串无意义的字符串,因此,在保密性方面做的很好;使用IECookiesView对该Cookie内容进行修改,再次打开网站http://Cookie2.d,此时将会要求重新登陆,因此,在完整性方面也得到了保证;在工作站二中使用Cookies & Inject Browser工具将此Cookie提交到网站http://Cookie2.d,网站未要求登陆直接打开了“Default.aspx”页面,可见,在可鉴别性方面没有得到保证,即Cookie可以被盗用。因此,这种Cookie设计的方法是不安全的。
Ø        MAC地址/IP地址绑定加密Cookie模型设计的实现[4,5,6,7,8,9]
打开Microsoft Visual Studio 2005打开一个ASP.NET网站,网站位置为“本地IIS”中的“演示网站三”,新建登陆页面“Login.aspx”存放于网站根目录,Login.aspx窗体中放置登陆框,用户可以在这里输入用户名和密码登陆系统。新建页面Default.aspx,此页面限制只有注册用户登陆之后才可以查看,并且还会检查当前请求的客户端的MAC地址或者IP地址是否与初始生成Cookie的客户端相符,只有相符才允许进入该页面,在页面中显示的是客户端的MAC地址或者IP地址以及从Cookie中读取的密文信息以及从密文中解密出来的明文信息。新建一个类“GetClientMac”用以获取客户端的MAC地址或IP地址。编辑Web.config文件,加密解密方法以及加密解密的密钥,Form身份验证的各项参数(包括Cookie名,Cookie模式、Cookie有效期、Cookie路径等),添加数据库连接来连接SQL Server中的aspnetdb数据库来提供用户。
对该模型安全性的验证方法为:从工作站一打开网站http://Cookie3.d,使用正确的用户名“dsz”和密码“dsz_123456”登陆,并选中“下次自动登陆”复选框,这样Cookie就被保存在“C:\Documents and Settings\用户名的文件夹\Cookies”中,用记事本将此文件打开administrator@Cookie3.d.txt这个文件,可以发现Cookie文件中的内容是一串无意义的字符串,因此,在保密性方面做的很好;对该Cookie内容进行修改,再次打开网站http://Cookie3.d,此时将会要求重新登陆,因此,在完整性方面也得到了保证;在工作站二中使用Cookies & Inject Browser工具将此Cookie提交到网站http://Cookie3.d,页面提示“MAC/IP”验证失败,并要求用户登陆,可见,在可鉴别性方面得到了保证,即Cookie不会被盗用。因此,这种Cookie设计的方法是安全的。
需要指出的是,此模型存在缺陷,其一:若工作站处于局域网中,不能防止同一局域网中的用户盗用Cookie;其二:若生成Cookie的时候使用的是客户端IP地址,则当该客户端IP地址发生变更,服务器会要求用户重新登陆;其三:MAC地址和IP地址均可以伪造,别有用心的人得到Cookie后,仍可以伪造用户电脑的MAC地址或者IP地址。虽然有缺陷,但是毕竟服务器不可能对客户端电脑做到完全的保护,需要用户自己保护好自己的隐私,总的来说这些缺陷不会构成普遍的安全隐患,实用性仍然值得推广。下一节中将介绍程序开发中的具体代码实现。
 

C#安全Cookie的设计开发
4.3 程序设计开发说明
本安全Cookie的设计中用到了一个函数GetClientMac()来获取客户端的MAC地址,若获取MAC地址失败则返回IP地址,文件GetClientMac.cs中该函数主要代码如下:
public class GetClientMac
{
         [DllImport("Iphlpapi.dll")]     //调用Windows IP辅助API应用程序接口
         private static extern int SendARP(Int32 dest, Int32 host, ref Int64 mac, ref Int32 length);         //win32的API发送ARP报文
         [DllImport("Ws2_32.dll")]       //调用Windows Sockets应用程序接口
         private static extern Int32 inet_addr(string ip);   //ip地址转换
         public GetClientMac(){}
         public static string GetCustomerMac(string userip)
         {   // 实现GetCustomerMac()方法,获取指定ip地址的主机mac地址
             try
             {
            string strClientIP = userip.Trim();
            Int32 ldest = inet_addr(strClientIP); //目的地的ip
            Int32 lhost = inet_addr("");   //本地服务器的ip 若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
= 6;
            int res = SendARP(ldest, 0, ref macinfo, ref len);//发送ARP来获取mac地址
            string mac_src = macinfo.ToString("X");   //转换mac地址为16进制表示的字符串
            if (mac_src == "0")
            {
                return userip; //无法获取mac地址则返回ip地址
            }
            else
            {
                while (mac_src.Length < 12)
                {
                    mac_src = mac_src.Insert(0, "0");//mac地址不足12位的在前面加0
                }
                string mac_dest = "";
                for (int i = 0; i < 11; i++) //将源mac转换成常见的每2字符下划线间隔格式
                {
                    if (0 == (i % 2))
                    {
                        if (i == 10)
                        {
                            mac_dest = mac_dest.Insert(0, mac_src.Substring(i, 2));
                        }
                      _dest = "-" + mac_dest.Insert(0, mac_src.Substring(i, 2));
                        }
                    }
                }
                return mac_dest;  //返回mac地址
            }
        }
        catch (Exception err)
        {
            return userip;    //出现任何错误返回ip地址
        }
    }
}
 
文件Login.aspx.cs是登陆验证程序的代码,加载页面时使用GetClientMac类中的GetCustomerMac()方法取得客户端MAC或者IP地址。登陆验证使用Membership成员中的ValidateUser()方法验证用户名和密码,通过验证则生成票据写入Cookie并跳转到Default.aspx页面,否则返回登陆页。用户登陆验证代码如下:
 
private string userMac;
    protected void Page_Load(object sender, EventArgs e)
    {
        userMac = GetClientMac.GetCustomerMac(Request.UserHostAddress);
//根据客户端ip取得客户端mac/ip地址
    }
    protected void LoginButton_Click(object sender, EventArgs e)
    {
        string userName = UserBox.Text;  //取得输入的用户名
        string passWord = PwdBox.Text;   //取得输入的密码
        if (Membership.ValidateUser(userName, passWord)) //验证用户身份
        {
            FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.AddYears(50), false, userMac);
//生成身份验证票据
若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn);
//对身份验证票据加密
            HttpCookie EncryptCookie = new HttpCookie("EncryptCookie");
            //建立一个Cookie对象
            EncryptCookie.Value = EncryptTicket;
            //将加密后的验证票据赋予Cookie值
            if (RemberMe.Checked)     //判断是否需要保留Cookie
            {
                EncryptCookie.Expires = DateTime.Now.AddYears((EncryptCookie);      //将Cookie发送到客户端
            Response.Redirect(FormsAuthentication.GetRedirectUrl(userName,false));
            //转到登陆前的页面
        }
        else
        {
            LoginMsg.Text = "登陆失败!用户名或密码错误。"; //用户身份验证失败的提示
        }
}
文件Default.aspx.cs为登陆成功后的信息显示页面代码,此页面打开时将判断Cookie,然后对Cookie进行三重验证,确认Cookie有效后才显示该页,否则返回登陆页。此页面需要使用异常处理模块来防止由于无发获取Cookie而产生的错误。此外,使用了FormsAuthentication.SignOut()注销Cookie。该页面代码如下:
private string userMac;
protected void Page_Load(object sender, EventArgs e)
{
    userMac = GetClientMac.GetCustomerMac(Request.UserHostAddress);
//根据客户端ip取得客户端mac/ip地址
    try
    {
       名为“EncryptCookie”的Cookie的值
       if (userMac == FormsAuthentication.Decrypt(EncryptCookie.Value).UserData)
       {  //将客户端MAC/IP同Cookie中存储的mac/ip进行对比,从而判断Cookie来源
       MacLabel.Text = userMac;
       Label1.Text += EncryptCookie.Name;
       TextBox1.Text += EncryptCookie.Value;
       Label3.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).Name;
       Label4.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).CookiePath;
                Label5.Text += FormsAuthentication.Decrypt(EncryptCookie. += FormsAuthentication.Decrypt(EncryptCookie.Value).Expired;
                Label7.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).IsPersistent;
                Label8.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).IssueDate;
                Label9.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).UserData;
                Label10.Text += FormsAuthentication.Decrypt(EncryptCookie.Value).Version;
            }
            else
            {     //mac/ip验证失败则执行强制注销操作,并警告提示
                ('MAC/IP验证失败,请重新登陆!');window.location.href='" + FormsAuthentication.LoginUrl + "'");
            }
        }
        catch {   //此页面程序发生任何异常则强制注销并转到登陆页
            FormsAuthentication.SignOut();
            Response.Redirect(FormsAuthentication.LoginUrl);
        }
    }  
4.4 调试经验
在程序开发过程中遇到了一些问题,通过查找资料,咨询老师,都得到了解决。
在程序开发的初始阶段,对ASP.NET内置的身份验证机制不了解,以为需要自己去建立一个用户资料的数据库,后来经过老师的指导,得知可以使用ASP.NET SQL Server安装向导(aspnet_regsql)来创建一个默认成员数据库,从而可以使用ASP.NET的Form验证机制。
在Web.config中配置数据库连接字符串connectionStrings时,程序运行出现配置错误的提示:项“LocalSqlServer”已添加。对于这个错误,开始有点摸不着头脑,后来
 

C#安全Cookie的设计开发
上网查证,得知在系统默认的配置文件中已经存在默认的名为LocalSqlServer的数据库连接字符串,因此,需要加入标记来忽略系统默认值,使用自定义的连接字符串。
在对Cookie的加密过程中,使用FormsAuthentication.Encrypt方法加密票据,但是对其加密过程和加密解密所用的算法却不清楚,于是查询资料,得知FormsAuthentication.Encrypt方法所用的加密解密方法需要在Web.config文件中添加machineKey节点来设置密钥和算法。
选择客户端特征信息时,起先只选用了MAC地址作为特征参数,在调试过程中,发现某些时候,如客户端安装有网络防火墙软件,程序并不能够获取客户端的MAC地址信息,所以最终选择使用IP地址作为候选特征,问题解决。
4.5 小结
经过以上各个具体步骤的实施,完成了系统实现。采用的系统模型准确的描述了安全Cookie的各个特性,通过使用ASP.NET身份票据加密方法实现了“机密性”和“完整性”二个问题,使用MAC/IP地址绑定Cookie实现了“可鉴别性”方面的问题,因此模型合理;在设计上采用ASP.NET的网站架构,充分利用了ASP.NET的特性,使用简单的代码实现了所需求的功能,无论在效率上还是在安全性方面都是很好的;实现系统模型后,使用安全检测工具对模型进行完整的测试,结论与理论上是完全相符的,因此,本系统的实现是成功的,达到了设计的预期目标。
本模型的具体运行状态可以归纳如下,用户从登陆界面登陆并选择下次自动登陆,即保存Cookie,通过用户名和密码校验后进入授权页面,下次进入同一网站时,网站读取用户的Cookie,并对Cookie信息进行3重检验,根据Cookie判断是否可以访问授权页面。
对于系统的具体运行结果及分析,在第五章中详细介绍,可以直观的看到各种模型的对比及优劣分析。
第五章 系统运行结果和分析
5.1 实现结果分析
5.1.1常规Cookie模型实现的分析
如图5.1.1-1,输入网址http://Cookie1.d,打开明文Cookie系统的登陆界面,登陆时选中“下次自动登陆”复选框,则登陆成功后Cookie信息会被保留在客户端硬盘中。下次打开网站则不会要求登陆。

图5.1.1-1 明文Cookie系统的登陆界面
如图5.1.1-2,使用正确的用户名“dsz”和密码“dsz_123456”登陆成功后的页面,显示了Cookie名和该Cookie的原始值,可以发现该信息是明文的。

图5.1.1-2 明文Cookie系统登陆后界面
如图5.1.1-3,从工作站的Cookie文件夹中打开administrator@Cookie1 [1].txt,可以清楚的看到Cookie是明文的形式存在。

图5.1.1-3 Cookie1.d的Cookie文件内容
如图5.1.1-4 是IECookiesView工具的界面截图,此软件可以读取和修改本机上的IE的Cookie,本设计中使用该软件进行Cookie安全性测试。

图5.1.1-4 IECookiesView软件界面
使用IECookiesView工具将Cookie1.d下生成的Cookie中的用户名“dsz”更改为“admin“,如图5.1.1-5所示。
若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
图5.1.1-5 使用IECookiesView工具修改Cookie1.d中的Cookie值
用记事本打开修改后的Cookie1.d文件administrator@Cookie1[1].txt,可以看到用户名被修改成为“admin”,如图5.1.1-6所示。

图5.1.1-6 Cookie1.d更改后的Cookie文件
重新打开浏览器输入网址http://Cookie1.d,发现Cookie值已经变成“admin”,可见明文Cookie系统的Cookie值确实可以修改,如图5.1.1-7。

图5.1.1-7 修改Cookie值后的default.aspx页
5.1.2加密Cookie模型实现效果
在工作站二中打开Cookies & Inject Browser工具,该工具除了可以浏览网页之外,还可以修改发送到服务器的Cookie信息,本设计中使用该工具来将工作站一中的Cookie从工作站二中发送到服务器,从而来测试Cookie的安全性。首先打开http://Cookie1.d,显示登陆页。如图5.1.1-8所示。
 

C#安全Cookie的设计开发
图5.1.1-8 Cookies & Inject Browser工具界面
使用Cookies & Inject Browser工具在Cookie栏中输入工作站一中所看到的Cookie信息“ClearCookie=dsz”,然后打开网站http://Cookie1.d,可以看到default.aspx被打开了,系统并没有跳到login.aspx去要求登陆。如图5.1.1-9所示。

图5.1.1-9 使用他人的Cookie成功通过验证
在工作站一中打开网站http://Cookie2.d,打开登陆页面,输入用户名密码,并选中“下次自动登陆”。如图5.1.1-10所示。

图5.1.1-10 加密Cookie系统登陆界面
登陆成功后,界面上显示了Cookie名、Cookie内容以及从Cookie中解密出来的相关信息,从图5.1.1-11中可以看出,Cookie内容是一长串无规则的字符串,用户无法得知其意义,只有Web服务器可以解密。

图5.1.1-11 加密Cookie系统登陆后界面
从工作站一的Cookie文件夹中打开administrator@Cookie2[2].txt文件,可以看到Cookie内容,但是内容是一长串经过加密的字符串,如图5.1.1-12所示。

图5.1.1-12 Cookie2.d网站的加密的Cookie文件
打开IECookiesView工具,将Cookie2.d网站的Cookie值进行修改,如图5.1.1-13所示。

图5.1.1-13 修改Cookie2.d网站的Cookie
修改完成后,用浏览器打开网址http://Cookie2.d,这时候浏览器并没有如同图5.1.1-7那样打开default.aspx页面,而是跳转到了登陆页login.aspx,可见,修改Cookie值之后,Web服务器拒绝了该Cookie。如图5.1.1-14所示。
若图片无法显示请联系QQ3710167,C#安全Cookie的设计开发系统免费,转发请注明源于www.lwfree.cn
图5.1.1-14 修改Cookie后网站Cookie2.d需要登陆
到工作站二中使用Cookies & Inject Browser工具打开网站http://Cookie2.d,网站正常的给出了登陆页面。如图5.1.1-15所示。

图5.1.1-15 工作站二中打开Cookie2.d网站
将工作站一中取得的Cookie2.d网站的Cookie填入Cookies & Inject Browser工具的Cookie栏中,在地址栏输入http://Cookie2.d,这时候网站没有要求登陆就跳转到了default.aspx页面,并解密出了Cookie值,如同在工作站一中登陆之后一样,可见该Cookie也被接受了,如图5.1.1-16所示。

图5.1.1-16 工作站一的Cookie被工作站二利用成功
5.1.3MAC/IP绑定加密Cookie模型分析
在工作站一中打开网站http://Cookie3.d,网站要求用户登陆,输入用户名“dsz”密码“dsz_123456”登陆,同时选中“下次自动登陆”。如图5.1.1-17。

图5.1.1-17 MAC/IP绑定加密Cookie系统登陆界面
登陆后网站打开页面default.aspx,显示用户相关信息,这里除了Cookie名、Cookie值、Cookie解密后的信息之外,还有一个客户端MAC地址或者IP地址的显示,与Cookie中解密出来的自定义数据是相符的,如图5.1.1-18所示。

图5.1.1-18 MAC/IP绑定加密Cookie系统登陆后界面
从工作站一的Cookie文件夹中打开administrator@Cookie3[1].txt文件,可以看到Cookie内容,但是内容是一长串经过加密的字符串,如图5.1.1-19所示。

图5.1.1-19 Cookie3.d用户登陆成功后Cookie文件的内容
打开IECookiesView工具,将Cookie3.d网站的Cookie值进行修改,如图5.1.1-20所示。

图5.1.1-20 修改Cookie3.d的Cookie值
修改Cookie之后重新打开网站http://Cookie3.d,此时网站给出登陆界面,要求用户登陆,如图5.1.1-21所示,可见,修改之后的Cookie并没有被服务器接受。
 
C#安全Cookie的设计开发
图5.1.1-21 修改Cookie后网站要求用户登陆
到工作站二中使用Cookies & Inject Browser工具打开网站http://Cookie3.d,网站正常的给出了登陆页面。如图5.1.1-22所示。

图5.1.1-22使用Cookies & Inject Browser工具打开网站http://Cookie3.d
使用Cookies & Inject Browser工具向网站http://Cookie3.d提交从工作站一中看到的Cookie信息,这时网站弹出警告提示“MAC/IP验证失败,请重新登陆!”,可见,服务器拒绝了该Cookie,如图5.1.1-23所示。

图5.1.1-23 Cookie3.d拒绝了非法来源的Cookie
通过以上的功能演示后,我们可以很清楚的看到,明文Cookie模型没有保证Cookie的机密性、完整性、可鉴别性;加密Cookie模型保证了Cookie的机密性和完整性,但是没有保证Cookie的可鉴别性;MAC/IP绑定的加密Cookie模型保证了Cookie的机密性、完整性、可鉴别性。
5.2 结果比较分析
在Cookie中存放明文的信息是没有任何安全性的,明文Cookie可以被任何人看到并获取其中的用户隐私,而且非常容易被伪造、盗用,严重的情况下会给用户带来巨大的损失。
使用强壮的加密算法来将Cookie信息加密并且加入电子签名看起来是安全的,因为即使Cookie泄露了,得到Cookie的人也无法解读出其中的内容,用户的隐私得到了保护,但是,当Cookie作为网站的用户身份识别凭证的时候,这种方法就明显不安全,如果非法用户得知了用户的Cookie,即使无法解读其中的内容,也可以使用该Cookie来登陆网站,冒充合法用户,所以单纯的加密Cookie的方法只能用来存储一些个性化信息,不可以用来验证用户身份,使用范围受到了局限
在第三种模型中,在Cookie中加入了客户端的特征信息(MAC地址或者IP地址),然后使用强壮的加密算法将Cookie加密并加入电子签名,从上面的演示中可以明显的看到,这种方法生成的Cookie具有较强的保密性,信息无法被篡改、可以有效的鉴别Cookie使用者的合法性。因此可以得出结论,使用MAC地址/IP地址绑定的加密Cookie是安全的。
5.3 小结
本次毕业设计通过三个Cookie实例模型的对比,使用一些测试工具充分证实了本设计中的安全Cookie设计达到了设计目标,使用目前比较先进的加密算法完成了Cookie的加密以及密钥的动态管理,保证了用户隐私不被泄露;同时,使用MAC/IP地址绑定到Cookie的方法实现了Cookie来源合法性的鉴别,达到了实现了安全Cookie的目标。
 
C#安全Cookie的设计开发
第六章 总结与收获
通过这个学期的认真学习与研究,成功的完成了本次设计的目标。在设计过程中,掌握了在微软.net框架下开发应用程序及Web程序的基本方法;对B/S架构有了深入的掌握;同时学会了Microsoft SQL Server 2005数据库的使用方法,掌握了ASP.NET下使用MSSQL数据库的方法;在开发Web程序的过程中,对HTTP协议及其通信过程有了深入的了解和掌握;对当前网络中的Web网站安全现状有了全面的认识,特别是Cookie使用过程中的安全问题进行了深入的研究;除此之外的一个重要收获是对国际上各种加密解密算法特别是对称分组加密和散列加密算法进行了全面的了解,对其安全性进行了深入的研究,学会了如何合理的选用各种加密算法;值得一提的是,在设计Web页面的过程中,掌握了HTML语言、CSS标记以及javascript脚本等网页设计中普遍使用的技术;尤为重要的是,在写论文的过程中,掌握了标准的学术论文的写法,这对将来的工作和学习都是非常重要的。
通过大学四年的学习,基本掌握了本专业的基础知识,培养了一定的专业技能,养成了良好的学习习惯;除了学习本专业开设的专业课程之外,利用课外时间对于目前流行的计算机新技术、实用技能积极吸收学习,掌握了一部分专业技术,这对走出校门的大学生来说,是非常有益的;大学里除了学习科学知识,最重要的还有培养人格,大学里我学会了如何做人,如何待人处事,为以后踏入社会做好了准备。
世界互联网的发展日新月异,网络安全也越来越收到业界重视,目前的互联网正在飞速发展,由电脑终端发展到手机终端,由低速到高速,从有线到无线。但是Cookie技术从提出到现在已经有15年的历史了,现在仍然活跃在互联网上,虽然其安全性一直遭受质疑,但是随着技术的发展,Cookie的安全性也被网站开发者所关注着,开发者采用各种方法来保证Cookie的安全性,取得了很好的效果,虽然目前已经有其它的技术试图来取代Cookie的地位,比如说session,但是Cookie在未来很长一段时间内是无法被取代的,在未来的IPV6网络中,必将会出现更有效、更安全的技术来保证Cookie的安全性。
 
谢辞
四年的大学生活不知不觉中就要结束了,在这段难忘的生活中,有我许多美好的回忆。我想,有许多人是我要用一辈子去铭记的,在这份大学的最后一页里,我要感谢的人很多。
首先要感谢我的学校,感谢在这四年中教给我的做人道理,让我从一个懵懂得高中生变成一个成熟的青年。
其次我要感谢我的论文指导老师刘云老师,在他的指导下我对本课题的研究领域有了全面的了解,并指导我完成了论文,在这里衷心的感谢他。
还要感谢的是我们班主任杨秋萍老师,在四年来她一直照顾我们的学习和生活,无微不至的关怀让我们很感激,所以在这里也一定要特别感谢她。
还要感谢的就是我的父母,在我大学四年的生活和学习中给予了无尽的关心和支持,对于他们我更是有千言万语,还是汇聚成一句话:感谢你们一直都伴随着我。
感谢大学四年中一直陪伴我走过的朋友、同学和所有我认识的和认识我的人,正是有了你们,才有我大学生活的丰富多彩,绚丽多姿!
最后我要感谢各位审阅论文和参与论文答辩的各位老师,感谢你们对我大学四年学习总结的验收。
参考文献
[1] 樊月华,刘洪发 著.《Web技术应用基础》.清华大学出版社.2006.238-239
[2] 胡忠望,刘卫东 著.Cookie应用与个人信息安全研究.《计算机应用与软件》第24卷.2007.3
[3] 肖伟民 姚绪良 赵一超 著.www上Cookie的研究及应用.《农机化研究》第二期.2001.5
[4] 曹锰舒新锋 著.《C#与ASP.NET程序设计》.西安交通大学出版社.2006
[5]《电脑编程技巧与维护》杂志社著.《C#编程技巧典型案例解析》.中国电力出版社.2005
[6] Mark M.Burnett.《拒绝黑客-ASP.NET Web应用程序安全性剖析》.电子工业出版社.2005
[7] 崔良海 著.《ASP.NET网络编程实用教程 C#版》.北京大学出版社.2006
[8] 李克洪 著.《实用密码学与计算机数据安全》.东北大学出版社.2001
[9]卿斯汉 著.《密码学与计算机网络安全》.清华大学出版社.2001
[10]沈世镒 著.《近代密码学》.广西师范大学出版社.1998
[11] Julia Case Bradley & Anita C.Millspaugh.《Programming in C# .NET》. Tsinghua University Press.2005
[12] Shweta Bhasin.《Web Security Basics》.Thomson Course Technology.2002
[13]James F.Kurose & Keith W.Rose.《Computer Networking: A Top-down Approach Featuring the Internet》Pearson/Addison Wesley.2005
[14] Mike Andrews, James A. Whittaker.《How to Break Web Software: Functional and Security Testing of We》. Addison-Wesley.2006
[15] James Gillies, Robert Cailliau.《How the Web was Born: The Story of the World Wide Web》.Oxford University Press.2000
[16] Robert J. Fischer, Gion Green.《Introduction to security》Seventh Edition. Butterworth-Heinemann.2003
[17] Serge Vaudenay.《A Classical Introduction to Cryptography: Applications for Communications》. Springer.2005
[18] Kevin Hoffman.《Microsoft Visual C# 2005 Unleashed》. Sams Publishing.2006
[19] Peter Thorsteinson, G. Gnana Arun Ganesh, Arun Ganesh. 《.NET Security and Cryptography》. Prentice Hall PTR.2003
[20] Marcus Goncalves, Kitty Niles.《Ipv6 Networks》McGraw-Hill Companies.2001
[21] William R. Stanek.《Microsoft Windows Server 2003: administrator's pocket consultant》. Microsoft Press.2003
[22] Louis Davidson, Kevin Kline, Kurt Windisch.《Pro SQL Server 2005 Database Design and Optimization》. Apress.2006
 
C#安全Cookie的设计开发

附录
附录 1 程序代码
本次毕业设计的程序代码已存储在光盘上,如下表:附表-1:
附表-1:毕业设计的程序和文件清单表




文件名称

文件说明(X:表示光驱盘符)

文件备注


Login.aspx

X:\主程序\明文Cookie\

用户登陆页面窗体


Login.aspx.cs

X:\ 主程序\明文Cookie\

用户登陆窗体程序代码


Default.aspx

X:\ 主程序\明文Cookie\

登陆成功后信息显示页窗体


Default.aspx.cs

X:\ 主程序\明文Cookie\

登陆成功后信息显示页代码


Web.config

X:\ 主程序\明文Cookie\

ASP.NET网站配置文件


Login.aspx

X:\ 主程序\加密Cookie\

用户登陆页面窗体


Login.aspx.cs

X:\ 主程序\加密Cookie\

用户登陆窗体程序代码


Default.aspx

X:\ 主程序\加密Cookie\

登陆成功后信息显示页窗体


Default.aspx.cs

X:\ 主程序\加密Cookie\

登陆成功后信息显示页代码


Web.config

X:\ 主程序\加密Cookie\

ASP.NET网站配置文件


Login.aspx

X:\ 主程序\安全Cookie\

用户登陆页面窗体


Login.aspx.cs

X:\ 主程序\安全Cookie\

用户登陆窗体程序代码


Default.aspx

X:\ 主程序\安全Cookie\

登陆成功后信息显示页窗体


Default.aspx.cs

X:\ 主程序\安全Cookie\

登陆成功后信息显示页代码


GetClientMac.cs

X:\ 主程序\安全Cookie\ App_Code

取MAC/IP地址的类代码


Web.config

X:\ 主程序\安全Cookie\

ASP.NET网站配置文件


Aspnetdb.mdf

X:\数据库\

SQL 2005网站数据库(公用)


ASPNETDB.MDF_log.LDF

X:\数据库\

数据库日志文件


040404008-杜世忠.rar

X:\毕业论文

毕业论文的压缩文件
附录 2  英语论文与翻译
英文原文摘自:
Aviel D.Rubin, Daniel E.Geer. A Survey of web security.  IEEE Computer  Volume 31, Issue 9, Sep 1998 Page(s):34 - 41
网络安全概论
Aviel D.Rubin AT&T Labs
Daniel E.Geer Jr. Certco
引言:为网络开发安全方法是一项艰巨的任务,一部分原因是因为总是在事件发生后才去考虑安全问题。作者提供了一项对于网络安全问题调查,把重点放在特别关注的领域,如服务器的安全性,移动代码,数据传输,和用户的隐私。
一、前言
早期的网页设计师没有受到指责,因为安全问题是在之后才产生的。在开始时,网页的最高目标是无缝的可用性。如今,由于国际互联的用户网络和迅速扩大的Web功能,可靠性和安全性变得至关重要的。从事网络安全建设的提供商必须考虑网络环境的特殊性,其中包括位置无关,无国籍状态、代码、用户移动性和陌生人到陌生的沟通。
在这篇文章中,当前调查的是网络的具体安全问题。鉴于网络的快速发展,产品必然是一个综合的短期的技术和长期的原则。重点是安全的服务器和主机环境、灵活的代码、数据传输、匿名性和隐私。这里不探究密码学、电子商务或入侵检测,因为这些并不是具体的网络,所涵盖的是别的方面。
二、服务器安全
在客户端-服务器环境中,主要关注服务器端,因为服务器是中央系统和信息资源库。威胁一般针对的是服务器,而客户端则远在威胁之外。从服务端保护客户端一般不讨论,除非需要关注客户端的隐私,下面将讨论这个问题。
本文使用基于UNIX的Apache服务器作为一个例子来描述安全问题。Apache服务器是基于国家超级计算应用中心(NCSA)的服务器 ,是部署最广泛的服务器(如需了解更多关于Apache,见http://apache.org )。CERN的服务器几乎都是Apache服务器,是有据可查的。可悲的是,很多商业服务器已经偏离了对方,并且偏离了互联网的现存标准。当然,不能以偏概全。不过,无论运行何种Web服务器软件,有些情况是相同的,如安全配置,认证和准入问题,以及对动态内容的处理方法。
2.1、基本配置
安全问题最大的原因是管理不善。在分布式系统中,首先影响安全的管理是系统的配置。一个糟糕的系统配置可能意味着灾难。如果配置失控,就很难对系统的运行特征进行有效的管理。由于系统的复杂性增加,就凸现了一个问题:未能使系统符合安全策略而导致增加混乱和可被利用的漏洞。
网络服务器配置文件存在于服务器的根目录。配置文件完全是指令和注释。一项指令,是一个HTTP后台程序认识的关键字,加上一些参数。指令是大小写和空格不敏感的。他们控制的文件中包含的用户名和密码,组名及密码,以及文件树中文件的存取权限,包括默认权限和本地越权。
2.2、建立根
Web服务器有两个根目录:服务器的根目录,其中包含服务器的控制信息;文件根目录,其中包含的内容一般是服务器的根目录的子目录。文件根目录是当浏览器URL只包含服务器的名称(如http://web.mit.edu)时候的位置。服务器的根目录和文件根目录的配置文件是机密的并且只有在必须知道的情况下才可见。
最常见的错误,是系统管理员以root的身份运行Web服务器。一开始的时候绑定传统WWW的端口80–专用的80端口-使用root权限,但以root的身份运行Web服务器,此后造成了隐患。
最常见的修复是以匿名方式运行Web服务,但如果其他程序也以匿名方式运行,特权就混合了。因此,最好的做法是以普通用户身份运行服务器,譬如,Webserver,使用一个单独的用户ID和用户组,如为“www”。通常情况下,用户Webserver的主
 
C#安全Cookie的设计开发
目录是服务器的根目录,并包含文件根目录。只有WWW组可以存取服务器日志和服务器配置文件。用此方法, Web服务器的配置文件中指定了哪些用户实际运行-即,HTTP后台程序绑定了HTTP专用端口后,服务器执行“SUID Webserver” (设置用户ID为Webserver)。Web服务器二进制程序的所有者与Web服务无关,决不能设置suid。假设授权和特权用户以外的用户拥有了执行可执行文件的权限,并且可以利用程序打开和关闭特权,也能管理其他用户。这样一来,Web服务器以一个有读取任意文件权限的组ID运行,但它并没有写入权限以及自己的配置文件。通过此策略,一个被入侵的Web服务器,将不会导致主机系统的深度渗透。
2.3、本地控制问题
当用户请求URL中的网页, 服务器端以HTML代码的形式发送一个文件或命令的输出到输出流中。换句话说,它是动态的而不是静态的内容。包包含三个相关要求中的一个:,将文件“foobar”插入到内容中; ,将“/bin/date”插入到输出中;或 ,插入到输出的额外内容,但服务器脚本使用搜索关键字作为参数来专门运行。
服务端包括非常有用,但他们要花费计算开销,失去可移植性,并导致安全漏洞。如果有必要,最好的做法是要禁用执行功能。许多网站管理员的安全方案,允许越权到每个目录的根上。使用服务端包括,能够方便的使局部例外于全局策略来隔离来自一个深层的子目录的安全漏洞的威胁,不怀好意的用户可以通过这些漏洞来控制该子目录。使用服务器端包括,网站管理员应禁用子目录越权的能力,除非该越权是必需的。
2.4、验证
Web服务依赖于域名服务。如果不怀好意的人控制了域名服务,任何完全基于关联的域名和网络地址的安全措施将无用武之地。
基本身份验证只是简单的将用户名和密码公开的在整个网络上传输。这明显会造成密码被截获风险。为了在每个目录或每个服务器的基础上使用访问控制,可以将用户名和IP地址结合起来。用这种方法,服务器可以自下而上的评估文件权限——也就是说,首先查询当前目录,然后进入上层目录,以此类推,返回到文档根目录。这与大多数系统的文件系统的工作方式是相反的。
与基本验证类似,摘要式身份验证的双方知道一个共享的密码 ,但在完成验证的过程中不需要公开的发送密码。摘要身份验证使用一个简单的口令来验证密码:交换应答。在此方法中,摘要方案要求用户使用一个临时值-一个一次性的凭证(通常是一个大的随机数)。一个有效的应答是一个包含用户名、密码、临时值、HTTP方法和所请求URL这些信息的校验和(默认情况下,MD5校验)。
为了使客户端验证服务器,可以在传输层使用公共密钥的身份证书。虽然尚未广泛采用,客户端证书也可以被用来从服务器验证客户端。假设公共密钥的身份证书的使用很普遍,就需要高效的公共密钥基础设施,包括双方的证书颁发及撤销。这一基础设施并不存在,也许多半是在小规模的应用中,如在一个组织内。
当使用FTP来进行文件传输,FTP守护进程( ftpd )通常是建立一个匿名FTP服务器。在这种情况下,匿名实际上是指未经认证的。互联网安全系统的“匿名FTP常见问题解答”对使用匿名FTP的安全性有完善的文档 。至少,系统管理员应运行高质量的FTP守护进程,并确保它是chroot'd(是一个对限定文件访问的UNIX/Linux安全测量标准)。如果FTP区与HTTP区有重叠,上传必须与服务的内容隔离。任何Web服务器都会自动的从服务目录中读取或执行某些文件。聪明的攻击者完全可以使用FTP把命令放到HTTP后台程序可以找到的地方。
2.5、脚本
几乎所有的Web服务器都必须处理某些类型的动态内容。通用网关接口,或CGI ,是一种元语言,或中间设备,允许内容互动。核心理念是可靠的和经过证明的——一个独立于平台的编程语言为脚本。在某种意义上,CGI是编程产生HTML文件。
CGI的表达语言的唯一要求就的是,它必须与HTTP的守护进程使用相同的环境变量,它必须从标准输入读取和写入标准输出。因为CGI与程序会话,它包括传递参数和接收返回值;URL和HTML表单都可以携带。非脚本别名的CGI是指CGI程序可以出现的任何目录中,只要他们有适当的文件名扩展。脚本别名的CGI是指CGI程序只可以存在于明确命名的目录中,通常在服务器的根目录的/CGI子目录中。大多数具有安全意识的网站都是这样做的。
服务器从左至右分析URL:议定结构规定了如何连接到服务器,一旦有连接,该服务器按顺序分析路径的每一个部分。一旦分析出网址中的引导字符子串,就会运行一个脚本或者显示一个文档,URL中其余的信息将会交给文档作为参数。这就是所谓附加路径信息。
CGI脚本通常以用Perl、Tcl、Java、Python或者C语言编写。不论网站服务器中有多少网页,它都是使用相同的用户运行CGI脚本。因此,不同人编写的CGI脚本都是使用同一用户的身份运行,并且所有脚本有相同的权限和相互关系。
许多著名的系统入侵,可以被追查到是由于攻击者发送程序无法处理的数据。以一个具体的网站为例,考虑表单。主表单现在已经比较常见了,如订单表,传送给用户的表单中已经包含了一些数据(也许是在隐藏字段中)。用户填写表单的其余部分,然后传送给服务器,需要对表单内容采取一些措施,如处理呆伯特咖啡杯的订单。一个谨慎聪明的攻击者可能会修改隐藏的表单域去攻击,譬如说,50个呆伯特咖啡杯只付1个的价格。另一个变化是,修改系统命令的参数。CGI脚本中的任何普通语言(Perl,C和C++)都可以用这种方式利用,除非输入数据经过仔细过滤。
三、加固主机
主机安全侧重于主机系统的配置和运行方式,并为服务器安全性提供一个基础。
3.1、基本的威胁
挑战主机系统的安全性,包括复杂性,访问控制,和问责制。
l      因为在单机上很难预测安全敏感和非安全敏感的应用之间的互相影响,网站管理员通常在专用机器上运行安全敏感的子系统。据我们所知,值得信赖的系统——通过试验证明安全的系统设计——迄今在网络上发现的很少。我们所知,从来没有使用网络的正式评估标准,例如那些在美国国防部的橙皮书.
l      网站管理员必须给予根特权尽可能最佳的安全保障。如果攻击者获得超级用户访问权,他们的系统访问权是不受限制的。这个课题是包括在详细地在几个地方。主机的访问控制在其他种类的分布式系统中是根本不同的。为了做的正确,需要一个健全的安全策略,以及适当的执行机制。
l      网站是一个主动开放缺陷的系统;由许多不同来源的资源混合和匹配。因此,网站管理员必须尽职尽责。他们必须检查授权入口的所有行为,对每一个业务保存精确的记录。所有这些事件必须不可修改或注销后保留——保存在受保护的计算机日志以外的其它地方。
网站管理员应定期检查主机系统,如果主机系统经常变更并且独立运行则应该提高检查的频率。任何系统,一般来说如果有商业性质的检测和自己装的免费软件如COPS,TAMU,以及Tripwire等,都足够容易导致危险。鉴于网络的蓬勃发展的重要性,检测系统也可以检查更为明显的Web服务器安全问题。网站管理员和系统管理员可以在这一块进行密切的合作。
3.2、通知和恢复
通知服务,其持续运行安全事件的列表,在主机安全中扮演了重要的角色。例如著名的团体如计算机紧急反应小组(CERT)和计算机事件处理顾问功能(ciac)为网站管理员和系统管理员发布公告。在万维网组织也提供了类似的,虽然不那么正式的服务。花絮新闻“三个漏洞”介绍一些已经报告给计算机紧急反应小组的普遍的入侵案例。
另外一个主机的安全工具是事件管理系统,这是为了反应一些隐蔽类型的行为。这些系统主要部署在一些有需求的生产环境中,虽然也有几个商业和免费的事件管理系统可以使用。
最后,由于入侵是不可避免的,所以恢复是必须加以考虑的。如果一个网站管理员怀疑被人入侵,最好谨慎的对待这个错误。有几个晨后的可用的资源。最好的开始
 
C#安全Cookie的设计开发
是列出一个对入侵处理的清单。必须对Web服务有效,任何数据中心的一般问题很可能会反映在Web服务上。
四、确保数据传输安全
在数据传输中有两个根本不同的处理方法。在网络层的处理办法,加密和身份验证直接被加入到网路堆栈中,使传输受到保护,而不需要结合它的应用。传输到达远程系统后,操作系统在将其递交给服务器应用程序之前利用远程系统的网络堆栈自动解密和验证。在应用级的处理方法中,应用程序本身就是被修改了,以便在将数据流提交给操作系统和网络层之前加密。然后由接收服务程序解密。
这两种方法各有利弊,他们可以同时实施。传输安全的弱点是两端的安全连接。信用卡资料通过网络发送使用的是应用层的安全传输,一旦它已传输到远程服务器就很容易受到窃取。用户的键盘或应用程式本身也有弱点。另一方面,攻击者可以破坏网络级别的安全传输,利用可传递的信任和主机的安全漏洞来窃取数据在安全的网络传输之前。对于网络来说,应用层安全是更好的选择,因为它能更容易在传输代理之间界定信任界限。
4.1、SSL协议
而应用层安全的最佳的选择应该是网景通讯公司的安全套接字层(SSL)协议,目前是第三次修订版。SSL协议是流为基础的,它在初次握手的时候就构成了一个安全的通讯,然后就是应用与应用直接对话(使用加密的应用数据)和关闭连接的握手。
4.1.1、如何工作
当客户端连接时,服务器和客户端交换招呼消息来建立将要使用的相应版本的协议,确定可选的加密算法,交换密钥,并确定可选的数据压缩参数。服务器和客户端也可以相互请求X.509证书进行验证,包含将整个一系列的证书引导至核证机构。客户端产生大量的加密密钥并将它们传送到服务器,服务器从证书中取得公钥来加密。一共要用到4个密钥,在客户端到服务端和服务端到客户端分别用到单独的一对密钥。
一旦SSL完成初始握手,它就会进入一个不透明的数据模式,在其中的应用数据是通过加密的,序列化的,每个序列包括一个加密的校验以防止干扰。多种加密算法,包括rc4和DES都可以得到支持。完成交互后,它们执行完成握手和关闭连接的操作。网景已明确的将SSL设计成一个通用的协议,因此它可以为除HTTP以外的其它应用服务,包括(可能)电子邮件和数据库访问。如果网景的设想得到实现,SSL可以成为一个为许多不同的应用类型提供一个普遍的安全层。
4.1.2、SSL的问题
前两个版本的SSL有许多缺点,阻碍其广泛使用,尤其是申请涉及大量的风险或资金转移。举例来说,SSL的实现并没有使用客户端证书进行验证。相反,服务器让浏览器来验证自己,但没有可靠的机制来验证客户身份。这意味着,SSL的主要是用来建立一个交换密码的安全的连接。在概念上和技术上来说,这是非常粗糙的 。SSL遭受了一些被广泛宣传的缺陷,包括协议的缺陷和其随机密钥生成机制的严重缺陷。
使问题更糟的是,免费版的网景浏览器中仅包括40位密钥的RC4加密算法,并且受到美国出口管制法规的限制。一些个人机构暴力破解了40位密钥,并宣布了结果,引起了公众对SSL安全性的质疑。不过,这不是SSL的失败 ,而是政府政策所导致的结果。这个问题唯一的解决方案是要求客户购买美国版的网景浏览器——其中包括数字化的SSL加密标准(SSL/DES)。当然,要求用户购买网景浏览器完全失败的原因有很多公司要使用SSL:大量的安装免费版的网景浏览器。
4.1.3、SSL的可能性
网景目前正在制定一个编程接口将SSL集成到winsock2.0中。因为Winsock运行在虚拟的会话层,网景的方案是为Winsock管理程序增加一些调用以便允许任何程序请求一个到客户端或服务器的安全SSL连接。这种增补的规范对已经存在的应用完全没有影响 ,但对于未来的应用,可以通过简单的函数调用提高安全性。若完成了这种功能并得到广泛使用,它将在应用对应用的基础上提供与网络级传输类似的安全性。
SSL引起了显著的用户支持,主要是因为大量的网景浏览器客户基础。大多数商业网页服务器套件支持SSL,许多免费的网页服务器包含了SSL支持 。为了鼓励开发者在他们的程序中嵌入SSL,网景制定了执行参考,SSL标准,可供下载。
4.2、安全与出口控制
SSL的经验表明,出口控制在应用层的传输安全中是一个大问题。如果使用者必须依赖密码,那么就会被一个有动机的攻击者很快攻破,精心设计的安全协议也没有用武之地。法律规定在公共网络中使用低质量的加密对电子商务的发展是一种制约。
但是,由于一些国家政府的加密政策在正日益受到政治和法律上的挑战,情况似乎注定要改变。如果没有,最终可能会看到那些被纳入出口受限制的软件模块在国外商业中的蓬勃发展。出口管制政策是其中影响网络传输安全(或者更确切地说,不安全)协议的一个最大的单一因素。如果政府不积极的为消除这种结果而努力,就很难让商业界赞同这个标准。
五、移动代码的安全
移动代码包括在远程位置运行的通用的可执行文件。这种通用的脚本可以运行在任何连接互联网的电脑上,这些电脑可能打开了各种不同的应用程序。然而,这种功能是要付出代价的。从安全的角度来说,没有什么比一个综合的、同样性质的、通用的解释程序更有风险。事实上,解释程序是只会增加危险的浏览器的一部分——一个大型的、缺陷臭名昭著的软件包。
基本上有三个实用技术来确保移动代码的安全:沙箱模型、代码签名以及防火墙。沙箱模型将执行权限限制在一定的小范围。代码签名检查可执行代码的来源是否是可信赖的。两种方法的结合在JDK1.2和网景浏览器12中都得到了应用.防火墙的做法是限制程序作为一个可运行基础上的客户端。
除了这些办法,有一种名为“携证代码”的技术越来越引起人们的兴趣,移动程
 

C#安全Cookie的设计开发
序携带一个验证来确保代码特征符合要求。这项技术仍是在理论阶段。还不能确定是否可用,例如,在Java小程序和客户端资源之间管理访问控制。
六、匿名和隐私
用户浏览网站的行为信息是越来越多的被记录和传播。因此,随着互联网的功能的增加,所获得的方便和隐私的损失是平衡的。用户往往不会察觉这种损失。网络用户留下了一个数据副本,提供有关他们阅读的,他们在哪儿购物,他们购买了什么,他们是那种类型的人等等信息。
例如,Cookies让外国的服务器获取客户端存储器中的国家信息。因此,一个高容量的服务器可以跟踪大量关于用户浏览习惯的信息。多个服务器的协作,能够建立更多的信息。很多有针对性的广告公司将用户配置文件的信息共享并建立庞大的数据库,包含用户和其数据的副本。
尝试引进技术来保护用户的隐私,包括MIXES14,代理机制和拥塞。
戴维·乔姆的MIXES独创引入反流量分析。同样的技术已被用来提供匿名电子邮件16和匿名网站浏览。MIX是一个使用相应的公共密钥对处理的过程。它接受信息,解密,然后将其转发。也可以使用一个MIX网络,每个MIX消除一个加密层然后信息以源状态在MIX网络中通过到达目的地。
MIX对解决匿名电子邮件问题是非常适合的。当用户选择了一套值得信赖的回邮器(电子邮件MIXES),邮件的收件者并不能得知消息的来源。如今有很多这种回邮器可以使用(见http://www.cs.berkeley.edu/~raph/remailer-list.html上面的列表 )。MIXES不是很适合用于同步通信,如浏览网页,因为第一个MIX和最后一个MIX之间会泄露发送者和接收者的身份认证,基于内容和时间的请求。此外,利用公共钥匙加密阻碍系统性能。采用MIX来进行网页浏览是否会被广泛的使用还有待观察。
更轻量级的做法在客户端和所有的服务器之间是介入一家著名的代理。代理重写所有客户端请求,以致目的服务器没办法识别请求来源。这是Anonymizer(http://www.anonymizer.com/)和朗讯个性化网页助手所提出来的方案。不幸的是,除非使用加密,否则系统管理员或任何可以在本地网络中窃听的人都能在客户端和服务器的连接上监视所有内容。而且,代理服务器的管理员必须受信任,不会储存或透露用户活动的信息。
当以一个群体来访问网站,他们所进行的任何行动都会被认为是整个群体的行动,从而个人用户相对相对来说是匿名的。群体系统运行于Windows和UNIX平台,并已部署在互联网上。群体分析遇到了很多反对者——如本地窃听者,系统管理员,群体成员合作组织,高端服务器——并且据我们所知目前唯一的办法是为匿名提供一些正式的保证。
七、总结
网络安全状况非常糟糕。大量的安全厂商的软件平均质量不断降低;只有少数厂商能提供对无形中的和难以避免的安全保障。然而,如果我们只有少量的供应商开始参与,我们的命运可能与几个农民种植相同品种的玉米相似。至此,网络的固有倾向的多样性和创新性使我们单在安全(和其中的固有风险)上要不遗余力。设立一个专门管理统一公钥的机构这个想法值得我们观望。
Web安全机制是一系列聪明、特别的成就的集合,它是为了改善系统的安全性,其关注度超过了最初的设计。有证据表明,不管怎么样,网络的商业应用将不可避免地导致更严重的安全问题。公共密钥技术在陌生人对陌生人的交流和网络的不区别糟粕的特征上具有独特适用性,强烈主张公开密匙基础建设作为基础,否则网络安全将挂起。对于网上交易的价值,网上安全交易中可信的管理例子在比例上将超过有风险的管理例子。这将在一定意义上解决提高安全性中其他的棘手问题,主要是用户群快速增长而导致的技术贫乏。
有几个在线安全资源可用,从Lincoln D. Stein好的建议中(http://www.genome.wi.mit.edu/WWW/faqs/www-security-faq.html)找到非常有帮助的聚集和罗格斯大学的传播作品和普渡大学沿海实验室为互联网工程任务组发表的网站安全手册。这里讨论的安全领域——服务器和主机环境,数据传输,移动代码以及匿名性和隐私——都非常活跃,但是已经投入这些领域的大量的资金正在稳步提高新观点的门槛,在值得做出努力之前需要确定这些观点是足够好。这些都是有趣的时期。
 
 
 
 
 
设为首页 | 加入收藏 | 网学首页 | 原创论文 | 计算机原创
版权所有 网学网 [Myeducs.cn] 您电脑的分辨率是 1280 x 720 像素
Copyright 2008-2020 myeducs.Cn www.myeducs.Cn All Rights Reserved 湘ICP备09003080号 常年法律顾问:王律师