CTF学习之0基础入门笔记(二)

继上一篇CTF学习之0基础入门笔记(一),继续学习!


前言

从这里才是搞网络安全真正入门的开始!

这一节需要花费记得东西多一点,并且主要是靶场的搭建,本人在搭建靶场过程中,主要用虚拟机,下面介绍了四种靶场,并在虚拟机上应用的方法,后续会继续讲怎么用这几种靶场。


提示:以下是本篇文章正文内容,下面案例可供参考

一、HTTP

1、HTTP的作用

HTTP 协议(Hypertext Transfer Protocol,超文本传输协议),是一个客户端请求和响应的标准协议,这个协议详细规定了浏览器和万维网服务器之间互相通信的规则。用户输入地址和端口号之后就可以从服务器上取得所需要的网页信息。

通俗来讲,HTTP协议作用的大致如下:

客户端通过浏览器——>获取——>服务端数据

客户端通过浏览器——>提交——>服务端后台程序(数据库服务器,缓存服务器储存服务器)

2、HTTP请求与响应报文信息

所有HTTP消息(请求与响应)中都包含一个或者几个单行现实的消息头,然后是一个强制空白行,最后是消息主体(可选)。

2.1、HTTP请求报文

所有HTTP消息(请求与响应)中都包含一个或者几个单行现实的消息头,然后是一个强制空白行,最后是消息主体(可选)。

以下是一个典型的HTTP请求:
在这里插入图片描述
注解字段的意思:

— 请求行 —
GET:一个说明HTTP方法的名词。GET方法要求服务器将URL定位的资源放在响应报文的数据部分,回送给客户端。使用GET方法时,请求参数和对应的值附加在URL后面,利用一个问号(“?”)代表URL的结尾与请求参数的开始,传递参数长度受限制。例如,/index.jsp?id=100&op=bind

— 请求头 —
Accept:描述客户端希望接收的响应body 数据类型。就是希望服务器返回什么类型的数据
Referer:告诉服务器,该请求来自哪里
Accept-Language:请求所支持的语言
User-Agent:一个特殊字符串头,使得服务器能够识别客户使用的操作系统版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等
Accept-Encoding:是否对数据进行压缩处理
Host:客户端指定自己想访问的http服务器的域名/IP 地址和端口号
Connection:一次连接(tcp三次握手) 多个请求(多个响应),会节省通讯效率
Cookie:服务器 发送给 浏览器 并 保存在本地的一小块数据,会在浏览器下次向同一服务器 再次发起请求时 被 携带并发送到服务器上

— 空行 —

— 请求主体 —
……
请求(响应)报文结构:

请求行(起始行)

请求头(响应头)

空行

请求主体(响应主体,ps:后区数据信息,文本,代码信息……)

2.2、HTTP响应报文

以下是一个典型的HTTP响应:
在这里插入图片描述
注解响应如下:

— 响应行/状态行 —
HTTP/1.1 200 OK :HTTP协议版本 状态码 状态描述

— 响应头 —
Server: Tengine: 服务器名称
Content-Type: text/html; charset=UTF-8:内容类型
Transfer-Encoding: chunked :发送给客户端内容不确定内容长度,发送结束的标记是0\r\n, Content-Length表示服务端确定发送给客户端的内容大小,但是二者只能用其一。
Connection: keep-alive: 和客户端保持长连接
Date: Fri, 23 Nov 2018 02:01:05 GMT: 服务端的响应时间
Content-Length:消息头规定消息主体的字节长度
ETag:浏览器根据HTTP请求的ETag验证请求的资源是否发生了改变,如果它未发生改变,服务器将返回响应。并且资源从浏览器缓存中读取,这样就不必再下次下载请求。
Vary:Accept-Encoding“标头,表示网站一般使用了GZIP压缩
Expires:RFC2616(HTTP、1.0)协议中和网页缓存相关字段。用来孔子缓存的失效日期。

— 空行 —

— 响应体 —
<!DOCTYPE html><html lang=“en”> …</html> : 响应给客户端的数据

2.3、HTTP通讯过程名词概念

2.3.1、请求方法

get:从服务端获取资源数据信息 (不会有请求主体信息)

head:和get方法类似 (不同之处在于服务器不会在其响应中返回主体信息,用于检查某一资源在向其提交get请求前是否存在)

post:向服务端提交资源数据信息 (字符信息)

put:向服务端上传指定资源 (试图使用包含在主体中的内容)

trace:服务器应在响应主体中返回其收到的请求信息的具体内容。 (主要用于检测客户端与服务器之间是否存在任何操纵请求的代理服务器)

option:服务器通常返回一个包含Allow消息头的响应,并在其中列出所有有效的方法 (要求服务器报告对某一特殊资源有效的HTTP方法)

2.3.2、URL

URL(统一资源定位符)是表示Web资源的唯一标识符,通过它即可获取其标识的资源。

最常用的URL格式如下:
protocol://hostname[:port]/[path/Ifile[?param=value1

这个结构中有几个部分是可选的。如果端口号与相关协议使用的默认值不同,则只包含端口号即可。

用于生成前面的HTTP请求的URL为:https://mdsec.net/auth/488/YourDetails.ashx?uid=129

具体注解:
http https ftp : // IP地址 域名信息: [8002] ( nginx 80 apache 81 tomcat 82……)/ 资源路径信息/XX/XX/静态资源(图片,html) | 动态资源(index.php)?id=202105

除这种绝对形式外,还可以相对某一特殊主机上的一个特殊路径制定URL,例如:
/auth/488/YourDetails.ashx?uid=129
YourDetails.ashx?uid=129

Web页面常常使用这些相对形式描述Web站点或应用程序中的导航

2.3.3、响应报文状态码信息

每条HTTP响应信息都必须在第一行中包含一个状态码,说明请求结果。根据代码的第一位数字,可以将状态码分为以下5类:

1xx —— 提供信息
2xx ——请求被成功提交
3xx ——客户端被重定向到其他资源
4xx ——请求包含某种错误
5xx ——服务器执行请求时遇到错误

还有大量的特殊状态码,其中许多状态码仅用在特殊情况下。下面列出渗透测试员在攻击Web应用程序是最有可能遇到的状态码及其相关的原因短语:

100Continue:当客户端提交一个包含主体的请求时,将发送这个响应。该响应表示已经收到请求消息头,客户端应继续发送主体。请求完成后,再由服务器返回另一个响应。

200 Ok:本状态码表示已经成功提交请求,且响应主题中包含请求结果

201 Created:PUT请求的响应返回这个状态码,表示请求已经成功提交

301 Moved Permanently:本状态码将浏览器永久重定向到另一个在Location消息头中指定的URL。以后客户端应使用新的URL替换原始的URL。

302 Found:本状态码将浏览器暂时重定向到另一个在Location消息头中指定的URL。客户端应在随后的请求中恢复原始URL。

304 Not Modified:本状态码指示浏览器使用缓存中保存的所请求资源的副本。服务器使用If-Modified-Since与if-None-Match消息头确定客户端是否拥有最新版本的资源。

400 Bad Request:本状态码表示客户端提供了一个无效的HTTP请求。当以某种无效的方式修改请求时(例如在URL中插入一个空格符),可能会遇到这个状态码。

401 Unauthorized:服务器在许可请求前要求HTTP进行身份验证。www-Authenticate消息头详细说明所支持的身份验证类型。

403 Forbidden:本状态码指出,不管是否通过身份验证,禁止任何人来访问被请求的资源

404 Not Found:本状态码表示所请求的资源不存在
405 Method Not Allowed:本状态码表示指定的URL不支持请求中使用的方法。例如,如果试图在不支持PUT方法的地方使用该方法,就会收到本状态码。
413 Request Entity Too Large:如果在本地代码中探查缓冲器滋出瀚洞,并就此提交超长数据串,则本代码表示请求主体过长,服务器无法处理。
414 Request URL Too Long:与前一个想用类似,本状态码表示请求中的URL过长,服务器无法处理。
500 Internal Server Error:本状态码表示服务器在执行请求时遇到错误,当提交无法预料的输入在应用程序处理过程中造成无法处理的错误时,通常会收到本状态码。应该仔细检查服务器响应的所有内容,了解与错误性质有关的详情。
503 Service Unavailable:通常,本状态码表示,尽管web服务器运转正常,并且能够响应请求,但服务器访问的应用程序,还是无法做出响应,应该进行核实,是否因为执行了某种行为而造成这个结果。

2.3.3、cookie信息

cookie的中文翻译是曲奇,小甜饼的意思。cookie其实就是一些数据信息,类型为“小型文本文件”,存储于电脑上的文本文件中。

Cookie就是一些数据,用于存储服务器返回给客服端的信息,客户端只是进行保存。在下一次访问该网站时,客户端会将保存的cookie一同发给服务器,服务器再利用cookie进行一些操作。利用cookie我们就可以实现自动登录,保存游览历史,身份验证等功能。

Cookie的处理分为:

服务器像客户端发送cookie
浏览器将cookie保存
之后每次http请求浏览器都会将cookie发送给服务器端

2.3.3.1、cookie的表示

cookie由变量名和值组成,类似Javascript变量。其属性里既有标准的cookie变量,也有用户自己创建的变量,属性中变量是用“变量=值”形式来保存。

而一般情况下,cookie是以键值对进行表示的(key-value),例如name=jack,这个就表示cookie的名字是name,cookie携带的值是jack。

2.3.3.1、cookie的组成

根据Netscape公司的规定,cookie格式如下:

Set-Cookie: NAME=VALUE;Expires=DATE;Path=PATH;Domain=DOMAIN_NAME;SECURE

NAME=VALUE:

这是每一个Cookie均必须有的部分。NAME是该Cookie的名称,VALUE是该Cookie的值。在字符串“NAME=VALUE”中,不含分号、逗号和空格等字符

Expires=DATE:Expires变量是一个只写变量,它确定了Cookie有效终止日期。该属性值DATE必须以特定的格式来书写:星期几,DD-MM-YY HH:MM:SS GMT,GMT表示这是格林尼治时间。反之,不以这样的格式来书写,系统将无法识别。该变量可省,如果缺省时,则Cookie的属性值不会保存在用户的硬盘中,而仅仅保存在内存当中,Cookie文件将随着浏览器的关闭而自动消失
  Domain=DOMAIN-NAME:Domain该变量是一个只写变量,它确定了哪些Internet域中的Web服务器可读取浏览器所存取的Cookie,即只有来自这个域的页面才可以使用Cookie中的信息。这项设置是可选的,如果缺省时,设置Cookie的属性值为该Web服务器的域名
  Path=PATHPath属性定义了Web服务器上哪些路径下的页面可获取服务器设置的Cookie。一般如果用户输入的URL中的路径部分从第一个字符开始包含Path属性所定义的字符串,浏览器就认为通过检查。如果Path属性的值为“/”,则Web服务器上所有的WWW资源均可读取该Cookie。同样该项设置是可选的,如果缺省时,则Path的属性值为Web服务器传给浏览器的资源的路径名
  可以看出我们借助对Domain和Path两个变量的设置,即可有效地控制Cookie文件被访问的范围
  Secure:在Cookie中标记该变量,表明只有当浏览器和Web Server之间的通信协议为加密认证协议时,浏览器才向服务器提交相应的Cookie。当前这种协议只有一种,即为HTTPS

2.3.3.2、cookie的HTTP传输

cookie在HTTP请求中将我们的cookie都进行了携带(浏览器只会携带在当前请求的url中包含了该cookie中path值的cookie),并且是以key:value的形式进行表示的。多个cookie用“;”进行隔开

cookie在HTTP响应中cookie的表示形式是,Set-Cookie:cookie的名字,cookie的值。如果有多个cookie,那么在HTTP响应中就使用多个Set-Cookie进行表示。

2.3.3.3、cookie的生命周期

cookie有2种存储方式,一种是会话性,一种是持久性。

会话性:如果cookie为会话性,那么cookie仅会保存在客户端的内存中,当我们关闭客服端时cookie也就失效了

持久性:如果cookie为持久性,那么cookie会保存在用户的硬盘中,直至生存期结束或者用户主动将其销毁

cookie到期时间取值:

负整数:cookie的maxAge默认为-1,表示只在浏览器内存中存储
0: 表示删除该cookie
正整数: 表示将该cookie持久化,浏览器会将cookie保存到硬盘上,存活相应时间

cookie我们是可以进行设置的,我们可以人为设置cookie的有效时间,什么时候创建,什么时候销毁。

2.3.3.4、Cookie使用的常见方法

java中Cookie对象的方法:

new Cookie(String name, String value):创建一个Cookie对象,必须传入cookie的名字和cookie的值

getValue():得到cookie保存的值

getName():获取cookie的名字

setMaxAge(int expiry):设置cookie的有效期,默认为-1。这个如果设置负数,表示客服端关闭,cookie就会删除。0表示马上删除。正数表示有效时间,单位是秒

2.3.3.4、Cookie的种类

Cookie 分为第一方Cookie 和第三方Cookie 两种。因为Cookie 会影响网站分析工具的测量,所以了解二者的差别是非常有必要的。

第一方Cookie——主机域名相关的Cookie

第三方Cookie——其他域名相关的Cookie

第一方Cookie和第三方Cookie,都是网站在客户端上存放的一小块数据。他们都由某个域存放,只能被这个域访问。他们的区别其实并不是技术上的区别,而是使用方式上的区别
比如,访问www.a.com这个网站,这个网站设置了一个Cookie,这个Cookie也只能被www.a.com 这个域下的网页读取,这就是第一方Cookie。如果还是访问www.a.com这个网站,网页里有用到www.b.com网站的一张图片,浏览器在 www.b.com请求图片的时候,www.b.com设置了一个Cookie,那这个Cookie只能被www.b.com这个域访问,反而不能被 www.a.com这个域访问,因为对我们来说,我们实际是在访问www.a.com这个网站被设置了一个www.b.com这个域下的Cookie,所 以叫第三方Cookie

第一方Cookie接受率高,更准确,没有特殊需要就用他。
第三方Cookie可以跨域跟踪,特别需求可以应用。

二、web渗透攻防环境搭建

1、虚拟主机系统部署(vmware)

Windows 2003/2008
Windows 7/10/11
Linux kali/centos

具体部署可以见哔哩哔哩上最新的kali安装视频(点开超链接,即可观看)。

对于我自己踩过的坑而言,新手小伙伴们在kali官网上下载的时候,最好搭外网,在Google浏览器下载,要不然中途很容易下载失败……说多了都是泪。

2、网络服务架构平台

Windows —— IIS+ASP架构平台
Linux ——LNMP LAMP LNMT
Windows ——LNMP LAMP LNMT (phpstudy安装,推荐上官网下载V2018版本,注意安装路径不要有汉字和特殊符号)

3、在网络平台部署项目代码(部署可以攻防测试网站)

3.1、bwapp

bwapp是一个非常适合白帽子练习学习的web应用靶场平台,有很全的漏洞练习例子,而且网上的资源也比较多,相比DVWA和pikachu算是比较完美的靶场了,而且靶场也分为不同的安全等级,有低、中、高三种,可根据自己的掌握情况选择不同等级来进行练习。

这是具体部署bwapp的超链接,可以点开看看。

3.2、pikachu

Pikachu是一个带有漏洞的Web应用系统,在这里包含了常见的web安全漏洞。如果你是一个Web渗透测试学习人员且正发愁没有合适的靶场进行练习,那么Pikachu可能正合你意。

这是具体部署pikachu的超链接,可以点开看看。

3.3、DVWA

DVWA(Damn Vulnerable Web Application)是一个用来进行安全脆弱性鉴定的PHP/MySQL Web应用,旨在为安全专业人员测试自己的专业技能和工具提供合法的环境,帮助web开发者更好的理解web应用安全防范的过程。

这是具体部署DVWA的超链接,可以点开看看。

3.4、mysql注入环境

web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行,导致参数中的特殊字符打破了SQL语句原有逻辑,黑客可以利用该漏洞执行任意SQL语句。

这是具体部署mysql的超链接,可以点开看看。

以上超链接都是本作者找的在虚拟机上安装的方法,可以借鉴一下。

总结

小伙伴们继续加油学习啊!

  • 4
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值