宣传一波 更好的阅读体验 👉 个人blog

---

1.Broken Authentication

1.Authentication Bypass

1.

Authentication Bypasses
Authentication Bypasses happen in many ways, but usually take advantage of some flaw in the configuration or logic. Tampering to achieve the right conditions.

Hidden inputs
The simplest form is a reliance on a hidden input that is in the web page/DOM.

Removing Parameters
Sometimes, if an attacker doesn’t know the correct value of a parameter, they may remove the parameter from the submission altogether to see what happens.

Forced Browsing
If an area of a site is not protected properly by configuration, that area of the site may be accessed by guessing/brute-forcing.

身份验证绕过
身份验证绕过以多种方式发生，但通常会利用配置或逻辑中的某些缺陷。篡改以达到正确的条件。

隐藏输入
最简单的形式是依赖于网页/DOM 中的隐藏输入。

删除参数
有时，如果攻击者不知道参数的正确值，他们可能会从提交中完全删除该参数，以查看会发生什么情况。

强制浏览
如果站点的某个区域未通过配置得到适当保护，则可以通过猜测/暴力破解来访问该站点的该区域。

2.

案例连接

您正在重置密码，但从您的提供商无法识别的位置或设备进行重置。因此，您需要回答您设置的安全问题。另一个问题是 这些安全问题也存储在另一台设备上（不是与您一起），而您不记得它们。

您已经提供了您的用户名/电子邮件，并选择了其他验证方法。

其实就是照着步骤复现就是了。。。有这么简单就好了

果然删除没有作用，看了提示说是修改参数

经过尝试发现修改成secQuestion需要有两个，且参数不为0和1就行，我试过数字或则字母都行

这位博主参看了源码，而且也讲得很详细👉WebGoat-8.2.2版靶机学习总结_webgoat8.2.2-CSDN博客

通过查看代码第59/61/88行可知，当参数中存在“%secQuestion%”的变量时请求就可以通过。符号%表示任意字符/串。

2.JWT tokens

1.Json Web Token

什么是JWT

Json Web Token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC 7519。

该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景，是目前最流行的跨域认证解决方案。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT 的原理

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

{
  "姓名": "张三",
  "角色": "管理员",
  "到期时间": "2018年7月1日0点0分"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

JWT 的数据结构

实际当中 JWT 长这个样子：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkNURkh1YiIsImlhdCI6MTUxNjIzOTAyMn0.Y2PuC-D6SfCRpsPN19_1Sb4WPJNkJr7lhG6YzA8-9OQ

它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的

JWT 的三个部分依次如下:

• Header（头部）
• Payload（负载）
• Signature（签名）

写成一行，就是下面的样子。

Header.Payload.Signature

每个部分最后都会使用 base64URLEncode方式进行编码

#!/usr/bin/env python
function base64url_encode($data) {
    return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
} 

Header

Header 部分是一个 JSON 对象，描述 JWT 的元数据，以上面的例子，使用 base64decode 之后：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

{
  "alg": "HS256",
  "typ": "JWT"
}

header部分最常用的两个字段是alg和typ。

alg属性表示token签名的算法(algorithm)，最常用的为HMAC和RSA算法

typ属性表示这个token的类型（type），JWT 令牌统一写为JWT。

Payload

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

除了官方字段，还可以在这个部分定义私有字段，以上面的例子为例，将 payload 部分解 base64 之后：

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkNURkh1YiIsImlhdCI6MTUxNjIzOTAyMn0

{
  "sub": "1234567890",
  "name": "CTFHub",
  "iat": 1516239022
}

注意：JWT 默认是不会对 Payload 加密的，也就意味着任何人都可以读到这部分JSON的内容，所以不要将私密的信息放在这个部分

Signature

Signature 部分是对前两部分的签名，防止数据篡改

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用”点”（.）分隔，就可以返回给用户。

参考链接

官网解释

阮一峰老师亲作(力推，写的很清晰)

JSON Web Token - Wikipedia

3.

这里直接解码就行了，可以用JSON Web Tokens 的也可以用Webwolf自带的功能

5.

尝试更改您收到的令牌并通过更改令牌成为管理员用户，并在您成为管理员后重置投票

点击投票之后抓包

解码

头部的算法改成none

payload部分的admin：false改成true

两个部分用base64加密，加密后拼接在一起如下面的格式，记得小数点

因为加密后会有=号，然后jwt需要把=去点

ewogICJhbGciIDogIm5vbmUiCn0.ewogICJhZG1pbiIgOiAidHJ1ZSIsCiAgImlhdCIgOiAxNzA0ODc4MTY1LAogICJ1c2VyIiA6ICJUb20iCn0.

改完发送就行了

6.

这是对第5题的解答？

Solution
The idea behind this assignment is that you can manipulate the token which might cause the server to interpret the token differently. In the beginning when JWT libraries appeared they implemented the specification to the letter meaning that the library took the algorithm specified inside the header and tried to work with it.

Signed JSON Web Tokens carry an explicit indication of the signing algorithm, in the form of the “alg” Header Parameter, to facilitate cryptographic agility. This, in conjunction with design flaws in some libraries and applications, has led to several attacks:

The algorithm can be changed to “none” by an attacker, and some libraries would trust this value and “validate” the JWT without checking any signature.

An “RS256” (RSA, 2048 bit) parameter value can be changed into “HS256” (HMAC, SHA-256), and some libraries would try to validate the signature using HMAC-SHA256 and using the RSA public key as the HMAC shared secret (see [McLean] and [CVE-2015-9235]).

For mitigations, see Sections 3.1 and 3.2.

— https://tools.ietf.org/html/rfc8725#section-2.1
What basically happened was that libraries just parsed the token as it was given to them without validating what cryptographic operation was used during the creation of the token.

Solution
First note that we are logged in as so first select a different user for example: Tom. User Tom is allowed to vote as you can see, but he is unable to reset the votes. Looking at the request this will return an in the response:Guestaccess_token

GET http://localhost:8080/WebGoat/JWT/votings/login?user=Tom HTTP/1.1

access_token=eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE2MDgxMjg1NjYsImFkbWluIjoiZmFsc2UiLCJ1c2VyIjoiVG9tIn0.rTSX6PSXqUoGUvQQDBiqX0re2BSt7s2-X6FPf34Qly9SMpqIUSP8jykedJbjOBNlM3_CTjgk1SvUv48Pz8zIzA
Decoding the token gives:

{
  "alg": "HS512"
}
{
  "iat": 1608128566,
  "admin": "false",
  "user": "Tom"
}

We can change the claim to but then signature will become invalid. How do we end up with a valid signature? Looking at the RFC specification is a valid choice and gives an unsecured JWT. Let’s change our token:adminfalsealg: none

headers:

{
  "alg": "none"
}

claims:

{
  "iat": 1608128566,
  "admin": "true",
  "user": "Tom"
}

If we use WebWolf to create our token we get:

eyJhbGciOiJub25lIn0.ew0KICAiYWRtaW4iIDogInRydWUiLA0KICAiaWF0IiA6IDE2MDgxMjg1NjYsDQogICJ1c2VyIiA6ICJUb20iDQp9
Now we can replace the token in the cookie and perform the reset again. One thing to watch out for is to add a at the end otherwise the token is not valid..

溶液
此分配背后的想法是，您可以操作令牌，这可能会导致服务器以不同的方式解释令牌。一开始，当 JWT 库出现时，它们实现了规范，这意味着库采用了标头中指定的算法并尝试使用它。

签名的 JSON Web 令牌带有签名的显式指示 算法，以 “alg” Header Parameter 的形式，以方便 加密敏捷性。这与设计缺陷相结合 一些库和应用程序导致了几次攻击：

攻击者可以将该算法更改为“无”，并且某些算法 库将信任此值并“验证”JWT，而无需 检查任何签名。

“RS256”（RSA，2048 位）参数值可以更改为 “HS256”（HMAC、SHA-256），一些库会尝试验证 使用 HMAC-SHA256 并使用 RSA 公钥作为 HMAC 共享密钥（请参阅 [McLean] 和 [CVE-2015-9235]）。

有关缓解措施，请参阅第 3.1 节和第 3.2 节。

• https://tools.ietf.org/html/rfc8725#section-2.1
  基本上发生的事情是，库只是在提供给他们的令牌时解析令牌，而没有验证在创建令牌期间使用的加密操作。

溶液
首先请注意，我们已登录，因此首先选择其他用户，例如：Tom。 如您所见，用户 Tom 被允许投票，但他无法重置投票。查看请求，这将在响应中返回：Guestaccess_token

GET http://localhost:8080/WebGoat/JWT/votings/login?user=Tom HTTP/1.1

access_token=eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE2MDgxMjg1NjYsImFkbWluIjoiZmFsc2UiLCJ1c2VyIjoiVG9tIn0.rTSX6PSXqUoGUvQQDBiqX0re2BSt7s2-X6FPf34Qly9SMpqIUSP8jykedJbjOBNlM3_CTjgk1SvUv48Pz8zIzA
解码令牌给出：

{
  "alg": "HS512"
}
{
  "iat": 1608128566,
  "admin": "false",
  "user": "Tom"
}

我们可以将声明更改为，但签名将失效。我们如何最终获得有效的签名？ 查看 RFC 规范是一个有效的选择，并给出了一个不安全的 JWT。 让我们更改我们的令牌：adminfalsealg: none

headers:

{
  "alg": "none"
}

claims:

{
  "iat": 1608128566,
  "admin": "true",
  "user": "Tom"
}

如果我们使用 WebWolf 创建我们的令牌，我们会得到：

eyJhbGciOiJub25lIn0.ew0KICAiYWRtaW4iIDogInRydWUiLA0KICAiaWF0IiA6IDE2MDgxMjg1NjYsDQogICJ1c2VyIiA6ICJUb20iDQp9
现在我们可以替换 cookie 中的令牌并再次执行重置。需要注意的一件事是在末尾添加 a，否则令牌无效。.

7.

查看parseClaimsJwt()的源码注释

Parses the specified compact serialized JWT string based on the builder’s current configuration state and returns the resulting unsigned plaintext JWT instance. This is a convenience method that is usable if you are confident that the compact string argument reflects an unsigned Claims JWT. An unsigned Claims JWT has a Claims body and it is not cryptographically signed. If the compact string presented does not reflect an unsigned Claims JWT, an UnsupportedJwtException will be thrown.

根据生成器的当前配置状态分析指定的紧凑序列化JWT字符串，并返回结果的无签名明文JWT实例。这是一个方便的方法，如果您确信紧凑字符串参数反映了未签名的声明JWT，则可以使用。未签名的索赔JWT具有索赔主体，并且它没有加密签名。如果提供的紧凑字符串不反映未签名的声明JWT，则将引发UnsupportedJwtException。
查看parse()的源码注释

Parses the specified compact serialized JWT string based on the builder’s current configuration state and returns the resulting JWT or JWS instance. This method returns a JWT or JWS based on the parsed string. Because it may be cumbersome to determine if it is a JWT or JWS, or if the body/payload is a Claims or String with instanceof checks, the #parse(String,JwtHandler) method allows for a type-safe callback approach that may help reduce code or instanceof checks.

根据生成器的当前配置状态分析指定的紧凑序列化JWT字符串，并返回结果的JWT或JWS实例。此方法根据解析的字符串返回JWT或JWS。由于确定它是JWT还是JWS，或者正文/有效负载是带有实例检查的声明或字符串可能会很麻烦，因此#解析（字符串，JwtHandler）方法允许一种类型安全的回调方法，这可能有助于减少代码或实例检查。

所以答案是

1

3

8.

这个需要找工具，可以用提示里面的hashcat

也可以用jwt-tools

我用的是jwt-tools，然后字典用提示里面的，下载命令

https://github.com/first20hours/google-10000-english

命令如下，jwt记得换成自己的

python3 jwt_tool.py jwt -C -d 字典
#参数-C表示对JWT进行压缩，以缩短字节长度。
#参数-d指定了一个字典文件，该文件包含用于尝试破解JWT的可能密钥列表。

然后提示我的密钥是shipping

把密钥换上去，然后username换成WebGoat，还有就是时间问题

因为令牌都有自己的时间，如果不改的话会提示

JWT expired at 2023-12-31T16:31:50Z. Current time: 2023-12-31T18:47:35Z, a difference of 8145871 milliseconds. Allowed clock skew: 0 milliseconds.

即过期了

exp尽量改大些就行了

9.

Refreshing a token
Introduction
In this section we touch upon refreshing an access token.

Types of tokens
In general there are two types of tokens: an access token and a refresh token. The access token is used for making API calls towards the server. Access tokens have a limited life span, that’s where the refresh token comes in. Once the access token is no longer valid a request can be made towards the server to get a new access token by presenting the refresh token. The refresh token can expire but their life span is much longer. This solves the problem of a user having to authenticate again with their credentials. Whether you should use a refresh token and an access token depends, below can find a couple of points to keep in mind while choosing which tokens to use.

So a normal flow can look like:

curl -X POST -H -d 'username=webgoat&password=webgoat' localhost:8080/WebGoat/login

The server returns:

{
    "token_type":"bearer",
    "access_token":"XXXX.YYYY.ZZZZ",
    "expires_in":10,
    "refresh_token":"4a9a0b1eac1a34201b3c5659944e8b7"
}

As you can see the refresh token is a random string which the server can keep track of (in memory or store in a database) in order to match the refresh token to the user the refresh token was granted to. So in this case whenever the access token is still valid we can speak of a “stateless” session, there is no burden on the server side to setup the user session, the token is self contained. When the access token is no longer valid the server needs to query for the stored refresh token to make sure the token is not blocked in any way.

Whenever the attacker gets a hold on an access token it is only valid for a certain amount of time (say 10 minutes). The attacker then needs the refresh token to get a new access token. That is why the refresh token needs better protection. It is also possible to make the refresh token stateless but this means it will become more difficult to see if the user revoked the tokens. After the server made all the validations it must return a new refresh token and a new access token to the client. The client can use the new access token to make the API call.

What should you check for?
Regardless of the chosen solution you should store enough information on the server side to validate whether the user is still trusted. You can think of many things, like store the ip address, keep track of how many times the refresh token is used (using the refresh token multiple times in the valid time window of the access token might indicate strange behavior, you can revoke all the tokens and let the user authenticate again). Also keep track of which access token belonged to which refresh token otherwise an attacker might be able to get a new access token for a different user with the refresh token of the attacker (see https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/ for a nice write up about how this attack works) Also a good thing to check for is the ip address or geolocation of the user. If you need to give out a new token check whether the location is still the same if not revoke all the tokens and let the user authenticate again.

Need for refresh tokens
Does it make sense to use a refresh token in a modern single page application (SPA)? As we have seen in the section about storing tokens there are two options: web storage or a cookie which mean a refresh token is right beside an access token, so if the access token is leaked chances are the refresh token will also be compromised. Most of the time there is a difference of course. The access token is sent when you make an API call, the refresh token is only sent when a new access token should be obtained, which in most cases is a different endpoint. If you end up on the same server you can choose to only use the access token.

As stated above using an access token and a separate refresh token gives some leverage for the server not to check the access token over and over. Only perform the check when the user needs a new access token. It is certainly possible to only use an access token. At the server you store the exact same information you would store for a refresh token, see previous paragraph. This way you need to check the token each time but this might be suitable depending on the application. In the case the refresh tokens are stored for validation it is important to protect these tokens as well (at least use a hash function to store them in your database).

刷新令牌
介绍
在本节中，我们将介绍如何刷新访问令牌。

token类型
通常，有两种类型的令牌：访问令牌和刷新令牌。访问令牌用于制作 API 对服务器的调用。访问令牌的生命周期有限，这就是刷新令牌的用武之地。一次 访问令牌不再有效，可以向服务器发出请求，通过提供 刷新令牌。刷新令牌可能会过期，但其生命周期要长得多。这解决了用户的问题 必须使用其凭据再次进行身份验证。是否应使用刷新令牌和访问令牌取决于： 下面可以找到在选择要使用的令牌时要记住的几点。

因此，正常流程可能如下所示：

curl -X POST -H -d 'username=webgoat&password=webgoat' localhost:8080/WebGoat/login

服务器返回：

{
    "token_type":"bearer",
    "access_token":"XXXX.YYYY.ZZZZ",
    "expires_in":10,
    "refresh_token":"4a9a0b1eac1a34201b3c5659944e8b7"
}

如您所见，刷新令牌是一个随机字符串，服务器可以跟踪它（在内存中或存储在数据库中） 为了将刷新令牌与用户匹配，已向其授予刷新令牌。 因此，在这种情况下，只要访问令牌仍然有效，我们就可以说是“无状态”会话，有 服务器端没有设置用户会话的负担，令牌是自包含的。 当访问令牌不再有效时，服务器需要查询存储的刷新令牌，以确保令牌 不会以任何方式被阻止。

每当攻击者保留访问令牌时，它仅在一定时间（例如 10 分钟）内有效。这 然后，攻击者需要刷新令牌来获取新的访问令牌。这就是为什么刷新令牌需要更好的保护。 也可以使刷新令牌无状态，但这意味着如果 用户吊销了令牌。 服务器完成所有验证后，必须向客户端返回新的刷新令牌和新的访问令牌。这 客户端可以使用新的访问令牌进行 API 调用。

你应该检查什么？
无论选择哪种解决方案，您都应该在服务器端存储足够的信息，以验证用户是否 仍然值得信赖。你可以想到很多事情，比如存储IP地址，跟踪刷新多少次 使用令牌（在访问令牌的有效时间窗口内多次使用刷新令牌可能表示奇怪 行为，您可以撤销所有令牌并让用户再次进行身份验证）。 此外，还要跟踪哪个访问令牌属于哪个刷新令牌，否则攻击者可能会 能够使用攻击者的刷新令牌为其他用户获取新的访问令牌 （请参阅 https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/，了解有关此攻击如何工作的精彩文章） 另外，要检查的一件好事是用户的 IP 地址或地理位置。如果您需要发出新的令牌检查 位置是否仍然相同，如果没有，请撤销所有令牌并让用户再次进行身份验证。

需要刷新令牌
在新式单页应用程序 （SPA） 中使用刷新令牌是否有意义？正如我们在本节中看到的 关于存储令牌，有两个选项：Web 存储或 cookie，这意味着刷新令牌就在 访问令牌，因此，如果访问令牌泄露，刷新令牌也可能被泄露。大多数时候 当然是有区别的。访问令牌在进行 API 调用时发送，刷新令牌仅发送 何时应获取新的访问令牌，在大多数情况下，该令牌是不同的终结点。如果你最终得到同样的 服务器，您可以选择仅使用访问令牌。

如上所述，使用访问令牌和单独的刷新令牌为服务器提供了一些不检查的杠杆作用 一遍又一遍地访问令牌。仅当用户需要新的访问令牌时才执行检查。 当然，可以只使用访问令牌。在服务器上，您存储的信息与存储的信息完全相同 存储 有关刷新令牌，请参阅上一段。这样，您每次都需要检查令牌，但这可能会 根据应用而适用。如果存储刷新令牌用于验证，则保护这些令牌也很重要（至少 使用哈希函数将它们存储在数据库中）。

10.

就如同session会有存活时长一样，JWT的access_token也是有相类似的机制。session失活后，系统会要求用户再次身份验证，通过则重新颁发session；JWT则可使用refresh token去刷新access token而无需再次身份验证。
登陆获取 access token, refresh token

WebGoat中提到：

应在服务器端存储足够的信息，以验证用户是否仍然受信任。您可以考虑的事情有很多，比如存储IP地址，跟踪使用refresh token的次数（在access token的有效时间窗口中多次使用刷新令牌可能表示奇怪的行为，您可以撤销所有token，让用户再次进行身份验证）。还要跟踪哪个access token属于哪个refresh token，否则攻击者可能会使用攻击者的refresh token为其他用户获取新的access token，请参阅https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation,还可以检查用户的IP地址或地理位置。如果需要发出一个新的令牌，请检查位置是否仍然相同，如果不同，则撤销所有令牌，并让用户再次进行身份验证。

这段话中关键信息是，服务器中可能存在：未校验access token和refresh token是否属于同一个用户，导致A用户可使用自己的refresh token去刷新B用户的access token。
WebGoat对于使用JWT的建议：

使用jwt令牌的最佳位置是服务器之间的通信。在普通的web应用程序中，最好使用普通的旧cookies。

根据题意，攻击者要利用Tom过期的刷新token来获取访问token，用Tom的账户购物

• 如何使用刷新token：https://segmentfault.com/a/1190000013151506
• 请求header信息中需要带上authorization: {$token}

点击here可以看到log

里面有token

解码后可以知道是tom的

然后点击购买抓包

把token放在Authorization: 后面

发送到repeater模块可以知道这个token是过期的

授权标头的一部分发送,这通常是使用Bearer令牌标准进行的，其中token以”Bearer “前缀开头，后跟实际的token值。

我们修改时间

1. exp（Expiration Time）：表示令牌的过期时间。它是一个时间戳，表示令牌在何时过期。该时间戳是使用纪元（Epoch）时间表示的，通常是以秒为单位的整数。
2. iat（Issued At）：表示令牌的签发时间。它也是一个时间戳，表示令牌是在何时被签发的。同样，该时间戳也是使用纪元时间表示的。

换算规则比如是Unix时间戳->北京时间

即1526217811->2018-05-13 21:23:31

我就是尽量大些就行了，发送即可

11.

这题我看writeup需要看源码。。。能找出sql漏洞

webgoat _v8.1全流程通关 - 让-雅克-卢梭 - 博客园 (cnblogs.com)

点击删除，抓包，获取token

更新数据，看源码利用了kid存在sql注入

{
  "alg" : "HS256",
  "kid" : "';select 'MQ==' from jwt_key --",
  "typ" : "JWT"
}
{
  "Email" : "jerry@webgoat.com",
  "Role" : [ "Cat" ],
  "aud" : "webgoat.org",
  "exp" : 5618905304,
  "iat" : 5524210904,
  "iss" : "WebGoat Token Builder",
  "sub" : "jerry@webgoat.com",
  "username" : "Tom"
}
secert_key=1

更换token就行了

3.Password reset

2.

Let’s first do a simple assignment to make sure you are able to read e-mails with WebWolf, first start WebWolf (see here) In the reset page below send an e-mail to (part behind the @ is not important) Open WebWolf and read the e-mail and login with your username and the password provided in the e-mail.username@webgoat.org

大概的意思就是叫你点击忘记密码用于重置密码，然后会发送一封mail给WebWolf，在WebWolf就可以看到你的新密码了，再回到登录页面重新输入账号和新密码就行了

4.

Security questions

This has been an issue and still is for a lot of websites, when you lost your password the website will ask you for a security question which you answered during the sign up process. Most of the time this list contains a fixed number of question and which sometimes even have a limited set of answers. In order to use this functionality a user should be able to select a question by itself and type in the answer as well. This way users will not share the question which makes it more difficult for an attacker.

One important thing to remember the answers to these security question(s) should be treated with the same level of security which is applied for storing a password in a database. If the database leaks an attacker should not be able to perform password reset based on the answer of the security question.

Users share so much information on social media these days it becomes difficult to use security questions for password resets, a good resource for security questions is: http://goodsecurityquestions.com/
Assignment

Users can retrieve their password if they can answer the secret question properly. There is no lock-out mechanism on this ‘Forgot Password’ page. Your username is ‘webgoat’ and your favorite color is ‘red’. The goal is to retrieve the password of another user. Users you could try are: “tom”, “admin” and “larry”.

安全问题
这一直是一个问题，对于许多网站来说仍然是一个问题，当您丢失密码时，网站会询问您 对于您在注册过程中回答的安全问题。大多数情况下，此列表包含一个固定的 问题的数量，有时甚至有一组有限的答案。为了使用此功能 用户应该能够自行选择问题并输入答案。这样用户就不会共享 这个问题使攻击者更加困难。

要记住的一件重要事情是，这些安全问题的答案应该以相同级别的 用于在数据库中存储密码的安全性。如果数据库泄漏，攻击者应该无法 根据安全问题的答案执行密码重置。

如今，用户在社交媒体上分享如此多的信息，因此很难将安全问题用于密码 重置，安全问题的一个很好的资源是： http://goodsecurityquestions.com/

分配
如果用户可以正确回答密码问题，则可以检索其密码。没有锁定机制 这个“忘记密码”页面。您的用户名是“webgoat”，您最喜欢的颜色是“红色”。目标是检索 其他用户的密码。您可以尝试的用户是：“tom”、“admin”和“larry”。

这题就是要在一直用户名的情况下搜寻“最喜欢的颜色”

所以我们直接burp抓包，加入Intruder模块进行爆破

还是和上面一样集束炸弹（第四个），对tom和最喜欢的颜色打上标记

在payload set 1 添加上tom admin 和 larry

set 2 加入颜色字典

可以在这里下载👉https://gist.github.com/mordka/c65affdefccb7264efff77b836b5e717

开始爆破后（可能需要多次才能获取答案），通过状态码（200）和length的不同寻找答案

因为答案最多三个，然后我们找最不同的就行了

最终找到admin:green,tom:purple,larry:yellow

5.

好像是叫选几个不容易被推断出答案的身份验证把。。。

这个自己选>2个就行了

6.

先用自己的账号发送重置密码的链接

会收到一封信，信里有重置密码的链接，样式为

http://localhost:8081/WebGoat/PasswordReset/reset/reset-password/2ad9c8c3-0cdc-4927-950f-ab348005dc4a

后面应该是用户id，然后主要是因为重置链接不变且永久有效导致的问题，我们只需要把后面的id换成tom的字符串就行了

但是如何获取Tom呢

我们可以向tom邮箱发送重置链接的信，虽然这样可以生成tom的字符串，但是我们不能登录tom的邮箱

所以我们可以在向tom邮箱发送重置链接的信抓包，然后修改host:localhost:8080为9090,这样的话是请求经过WebWolf

在数据包中，host表示接收这个请求的目的地的host，仅包括域名和端口号。例如，test.pay.com:8090。它是一个用于指定被请求资源的Internet主机和端口号的数据包头字段。

然后去webWolf的incoming request模块可以看到请求（最新消息在最下面）

发现tom的字符串，替换重置密码链接后面的id就行了

4.Secure Passwords

大部分都在讲如何构建一个安全的密码

4.

这个挺有意思的，可以知道你的密码强度（顺带一提测试博主的密码在不到2个月的时间就被爆破了。。。）

换了个强度高的密码需要100多年才能爆破（嘻嘻😏）

2.Sensitive Data Exposure

1.Insecure Login

不安全的登录

2.

其实就是模拟我们是中间人

被攻击人在登录时，我们截获数据包，可以看到用户名和密码明文传输

相当于就是不安全的登录