渗透测试-渗透测试常见的总结

炫彩@之星

已于 2023-01-20 00:41:34 修改

阅读量4.3k

点赞数 8

分类专栏：渗透测试文章标签：安全性测试 web安全安全

于 2022-05-18 20:05:26 首次发布

本文链接：https://blog.csdn.net/lza20001103/article/details/124848943

版权

渗透测试专栏收录该内容

93 篇文章 70 订阅

订阅专栏

渗透测试常见的总结

文章目录

渗透测试常见的总结
前言
一、渗透测试常见的总结
二、OWASP的十大漏洞
三、渗透测试面试总结
总结

前言

本次文章我给大家总结一下渗透测试过程中常见的总结，前些文章我给大家介绍了web渗透中常见的漏洞分析以及如何利用的方法与总结，后期将会进行内网渗透的学习，外网渗透就告一段落了，大家一定要好好复习与总结呀

一、渗透测试常见的总结

在这里我主要给大家讲一下当我们拿到一个域名url，通过子域名探测，进入到后台后，来到一个登录页面的时候，我们需要进行哪些步骤来完成接下来的渗透测试拿webshell的过程。

1. 登录页面以及端口扫描

（1）拿到一个网站，就先拿扫描器进行全方位的扫描，如果扫描不出来任何漏洞，我们就进行手工测试，也就是我们常说的黑盒测试。
（2）什么都扫不了的时候，登录页面，我们使用万能密码，admin’ or ‘1’ ='1 --+
（3）点击登录，进行抓包，复制到sqlmap跑一下，看看是否存在sql注入
（4）登录，抓包后看看是否为明文传输，或者用字典爆破用户名枚举，弱口令爆破
（5）一些中间件网站的默认密码和用户名
（6）目录扫描（7kbscan，御剑(扫后台，压缩包，备份文件)）
（7）看看是否有框架漏洞（cms）
（8）最重要的还是端口扫描，看看是否有重要的端口开放了，我们可以对端口进行访问获取敏感信息，这里用namp进行端口扫描

80 web服务端口（80-89）
1433 MSSQL
1521 Oracle
3306 MySQL
5432 Postgresql
443 SSL
50070/50030 hadoop
111/1025 NFS
8080 JBoss
7001 weblogic
3389 远程连接端口

这里给大家总结了常见的端口及用途

常见的端口号及其用途
一些常见的端口号及其用途如下：
21端口：FTP 文件传输服务
22端口：SSH 端口
23端口：TELNET 终端仿真服务
25端口：SMTP 简单邮件传输服务
53端口：DNS 域名解析服务
80端口：HTTP 超文本传输服务
110端口：POP3 “邮局协议版本3”使用的端口
443端口：HTTPS 加密的超文本传输服务
1433端口：MS SQL*SERVER数据库默认端口号
1521端口：Oracle数据库服务
1863端口：MSN Messenger的文件传输功能所使用的端口
3306端口：MYSQL 默认端口号
3389端口：Microsoft RDP 微软远程桌面使用的端口
5631端口：Symantec pcAnywhere 远程控制数据传输时使用的端口
5632端口：Symantec pcAnywhere 主控端扫描被控端时使用的端口
5000端口：MS SQL Server使用的端口
8000端口：腾讯QQ
80端口：HTTP 超文本传输服务
23：TCP

还有大家也要注意一下cookie的返回值，和常见的状态码的含义

cookie
expires
用于设定cookie的有效时间。在随后的浏览器会话中重复利用，直到到期为止。
domain
用于指定cookie的有效域
secure
设置这个属性，则仅在https请求中提交cookie
HttpOnly
设置这个属性，将无法通过客户端Javaspirt直接访问cookie

2.HTTP常见状态码及其含义

HTTP状态码含义
状态代码（也称作错误代码），指为服务器所接收每个请求（网页点击）分配的 3 位数代码。多数有效网页点击都有状态代码 200（“正常”）。如果"网页未找到"则会生产常见的404错误。了解各种状态代码的含义可以更迅速的发现问题，找到问题，解决问题。可以很大程度上的提高工作效率。下面是一些常见的状态代码。
1xx（临时响应）
用于表示临时响应并需要请求者执行操作才能继续的状态代码。
代码说明

100（继续）请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。

101（切换协议）请求者已要求服务器切换协议，服务器已确认并准备进行切换。

2xx（成功）
用于表示服务器已成功处理了请求的状态代码。
代码说明

200（成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果您的 robots.txt 文件显示为此状态，那么，这表示 Googlebot 已成功检索到该文件。

201（已创建）请求成功且服务器已创建了新的资源。

202（已接受）服务器已接受了请求，但尚未对其进行处理。

203（非授权信息）服务器已成功处理了请求，但返回了可能来自另一来源的信息。

204（无内容）服务器成功处理了请求，但未返回任何内容。

205（重置内容）服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。

206（部分内容）服务器成功处理了部分 GET 请求。

3xx（已重定向）
要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。Google 建议您在每次请求时使用的重定向要少于 5 个。您可以使用网站管理员工具来查看 Googlebot 在抓取您已重定向的网页时是否会遇到问题。诊断下的抓取错误页中列出了 Googlebot 由于重定向错误而无法抓取的网址。
代码说明

300（多种选择）服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作，或提供操作列表供请求者选择。

301（永久移动）请求的网页已被永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 Googlebot 某个网页或网站已被永久移动到新位置。

302（临时移动）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。

303（查看其他位置）当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。

304（未修改）自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销。

305（使用代理）请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。

307（临时重定向）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。

4xx（请求错误）
这些状态代码表示，请求可能出错，已妨碍了服务器对请求的处理。
代码说明

400（错误请求）服务器不理解请求的语法。

401（未授权）请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。

403（已禁止）服务器拒绝请求。如果在 Googlebot 尝试抓取您网站上的有效网页时显示此状态代码（您可在 Google 网站管理员工具中诊断下的网络抓取页面上看到此状态代码），那么，这可能是您的服务器或主机拒绝 Googlebot 对其进行访问。

404（未找到）服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。

如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具"诊断"标签的 robots.txt 页上发现此状态，那么，这是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。（该文件应当位于顶级域名上，且应当名为 robots.txt）。

如果您在 Googlebot 尝试抓取的网址上发现此状态（位于"诊断"标签的 HTTP 错误页上），那么，这表示 Googlebot 所追踪的可能是另一网页中的无效链接（旧链接或输入有误的链接）。

405（方法禁用）禁用请求中所指定的方法。

406（不接受）无法使用请求的内容特性来响应请求的网页。

407（需要代理授权）此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。

408（请求超时）服务器等候请求时超时。

409（冲突）服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。

410（已删除）如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。

411（需要有效长度）服务器不会接受包含无效内容长度标头字段的请求。

412（未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件。

413（请求实体过大）服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。

414（请求的 URI 过长）请求的 URI（通常为网址）过长，服务器无法进行处理。

415（不支持的媒体类型）请求的格式不受请求页面的支持。

416（请求范围不符合要求）如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。

417（未满足期望值）服务器未满足"期望"请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示，服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。
代码说明

500（服务器内部错误）服务器遇到错误，无法完成请求。

501（尚未实施）服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。

502（错误网关）服务器作为网关或代理，从上游服务器收到了无效的响应。

503（服务不可用）目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。

504（网关超时）服务器作为网关或代理，未及时从上游服务器接收请求。

505（HTTP 版本不受支持）服务器不支持请求中所使用的 HTTP 协议版本。

3.几种常见的http请求方式

1.GET

get方法请求指定的页面信息，返回实体主体。该请求是向服务器请求信息，请求参数会跟在url后面，因此，对传参长度有限制的，而且不同浏览器的上限是不同的（2k, 7~8k及其他）。由于get请求直接将参数暴露在url中，因此对于一些带有重要信息的请求可能并不完全合适。

2.POST

post请求是向指定资源提交数据进行处理请求，例如提交表单或者上传文件等。数据被包含在请求体中，POST请求可能会导致新的资源的建立和/或已有资源的修改。post方法没有对传递资源的大小进行限制，往往是取决于服务器端的接受能力，而且，该方法传参安全性稍高些

3.PUT

PUT方法是从客户端向服务器传送的数据取代指定的文档的内容。PUT方法的本质是idempotent的方法，通过服务是否是idempotent来判断用PUT 还是 POST更合理，通常情况下这两种方法并没有刻意区分，根据语义使用即可

4.DELETE

请求服务器删除指定的页面，DELETE请求一般会返回3种状态码：

200 (OK) - 删除成功，同时返回已经删除的资源
202 (Accepted) - 删除请求已经接受，但没有被立即执行（资源也许已经被转移到了待删除区域）
204 (No Content) - 删除请求已经被执行，但是没有返回资源（也许是请求删除不存在的资源造成的）
5.OPTIONS

允许客户端查看服务器的性能。（常见的是跨域预检Preflighted Reqeusts方法会采用该方法）。一般来说，开发中用到该方法是用来获取服务器支持的请求类型或者查看服务器类型，来确保接下来发送的请求够安全。该请求方法的响应不能缓存。如果该URI是一个星号（“*”），OPTIONS请求将试图应用于服务器，而不是某个指定资源；如果该URI不是星号，则只能用来获取该资源通信中可用的选项。

6.HEAD

类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头

7.CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

8.TRACE

回显服务器收到的请求，主要用于测试或诊断。

最后大家还要注一下x_forwarded_for的使用
x_forwarded_for：伪造地址（127.0.0.1）

以及CSRF的判断方法（是否有referer头），有就存在CSRF漏洞

最后就是报告的编写了，主要包括漏洞描述，漏洞地址，截图三方面。

二、OWASP的十大漏洞

1.sql注入

原理：
SQL 注入就是指 web 应用程序对用户输入的数据合法性没有过滤或者是判断，前端传入的参数是攻击者可以控制，并且参数带入数据库的查询，攻击者可以通过构造恶意的 sql 语句来实现对数据库的任意操作。

分类：
1、报错注入
2、bool 型注入
3、延时注入
4、宽字节注入

防御：
1.使用预编译语句，绑定变量
2.使用存储过程
3.使用安全函数
4.检查数据类型

1.获取数据库名
select SCHEMA_NAME from information_schema.SCHEMATA
2.获取表名
select TABLE_NAME from information_schema.TABLES
3.获取字段名
select * from information_schema.COLUMNS where TABLE_NAME=“users” and TABLE_SCHEMA=“security”
4.获取数据
select id,username,password from users

2.失效的身份认证和会话管理

原理:
在开发web应用程序时，开发人员往往只关注Web应用程序所需的功能，所以常常会建立自定义的认证和会话方案。但是要正确的实现这些方案却是很难的。结果就在退出、密码管理、超时、密码找回、帐户更新等方面存在漏洞。

防御：
1、区分公共区域和受限区域。
2、对最终用户帐户使用帐户锁定策略。
3、支持密码有效期。
4、能够禁用帐户。
5、不要存储用户密码。
6、要求使用强密码。
7、不要在网络上以纯文本形式发送密码。
8、保护身份验证 Cookie。
9、使用 SSL 保护会话身份验证 Cookie。
10、对身份验证 cookie 的内容进行加密。
11、限制会话寿命。
12、避免未经授权访问会话状态。

3.跨站脚本攻击 XSS

XSS是跨站脚本攻击，原理是攻击者向有XSS漏洞的网站中输入恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。

分类：反射型（非持久型）XSS、存储型（持久型）XSS、DOM型XSS.

区别：
DOM XSS和反射型XSS、存储型XSS的差别在于DOM XSS的代码并不需要服务器参与，触发XSS靠的是浏览器端的DOM解析，完全是客户端的事情。

什么是 HttpOnly?
如果您在 cookie 中设置了 HttpOnly 属性，那么通过 js 脚本将无法读取到cookie 信息，这样能有效的防止 XSS 攻击。

预防：
1.使用XSS Filter，即跨站脚本过滤器，用于分析用户提交的输入，并过滤可能存在的脚本攻击及恶意的THML或简单的HTML格式错误等。

2.输入过滤
输入是否仅仅包含合法的字符；
输入字符串是否超过最大长度限制；
输入如果为数字，数字是否在指定的范围；
输入是否符合特殊的格式要求，如E-mail地址、IP地址等
3.输出编码
<（小于号）转成 <

（大于号）转成 >
& （和号）转成 &
" （双引号）转成 "
’ （单引号）转成 ’
4.黑名单和白名单
5.内容安全策略（csp）：CSP用于限制浏览器查看您的页面，以便它只能使用从受信任来源下载的资源。

4.直接引用不安全的对象

定义：
不安全的直接对象引用（IDOR）允许攻击者绕过网站的身份验证机制，并通过修改指向对象链接中的参数值来直接访问目标对象资源，这类资源可以是属于其他用户的数据库条目以及服务器系统中的隐私文件等等。

出现的原因：
Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。
服务器上的具体文件名、路径或数据库关键字等内部资源被暴露在URL或网页中，攻击者可以尝试直接访问其他资源。

防御措施：
1.使用基于用户或会话的间接对象访问，这样可防止攻击者直接攻击未授权资源
2.访问检查：对任何来自不受信源所使用的所有对象进行访问控制检查
3.避免在url或网页中直接引用内部文件名或数据库关键字
4.验证用户输入和url请求，拒绝包含./ …/的请求

5.安全配置错误

定义：
安全配置错误可以发生在一个应用程序堆栈的任何层面，通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。

影响：
攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解。

防御措施：
1、配置所有的安全机制
2、最小原则，关掉或限制不使用的服务
3、更改默认账户信息
4、使用日志和警报
5、回显信息不显示任何与实际错误相关的信息
6、检查和修复安全配置项

6.敏感信息泄露

漏洞描述：
由于管理员或者技术人员等各种原因导致敏感信息泄露。许多web应用程序和app都无法正确保护敏感数据，攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

检测方法：
1、手工挖掘，查看web容器或网页源码代码，可能存在敏感信息。比如访问url下的目录，直接列出了目录下的文件列表，错误的报错信息包含了网站的信息。
2、工具挖掘，像爬虫之类的工具可以扫描到敏感文件路径，从而找到敏感数据。

防范措施：
1、对系统处理、存储或传输的数据进行分类，根据分类进行访问控制。
2、对用户敏感信息的传输和存储进行加密
3、强化安全意识

7.缺少功能级的访问控制

原理：
大多数Web应用程序的功能在UI页面显示之前,会验证功能级别的访问权限。但是,应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证,攻击者能够伪造请求从而在未经适当授权时访问功能。

测试方法：
1、保证合法授权用户可以访问成功
2、限制非法未授权用户的访问

防御措施：
1、设计严格的权限控制系统，对于每个请求和URL都要进行校验和权限确认，防止非法请求被执行
2、对于每个功能的访问，都要有明确的角色授权，采用过滤器的方式校验每个请求的合法性
3、实现Web访问的IP白名单列表，禁止不可信的IP访问Web系统

8.跨站请求伪造 CSRF

CSRF概念：
CSRF跨站点请求伪造(Cross—Site Request Forgery)，跟XSS攻击一样，存在巨大的危害性，你可以这样来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

攻击原理：
CSRF攻击攻击原理及过程如下：

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

分类：
GET型和POST型。

防御手段：
1、验证 HTTP Referer 字段。
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。
2、在请求地址中添加 token 并验证
在HTTP请求中以参数的形式加入一个随机产生的token（随机字符串），并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
3、二次验证
在转账等关键操作之前提供当前用户的密码或者验证码。二次验证可以有效防御CSRF 攻击。