diff --git a/2019/en/src/0xa1-broken-object-level-authorization.md b/2019/en/src/0xa1-broken-object-level-authorization.md index 9d9a0545e..f06c7839e 100644 --- a/2019/en/src/0xa1-broken-object-level-authorization.md +++ b/2019/en/src/0xa1-broken-object-level-authorization.md @@ -56,7 +56,7 @@ modify other users' account data. ## How to Detect -Access control weaknesses are best detected by **manual** means. **Code review** +Access control weaknesses are best detected by **manual** means. By simply searching for variables such as UserID's and account numbers that could possibly be ennumerated or URL paths that can be manipulated. **Code review** and **pentesting** are a great way to detect these issues. Some automation may be used to detect the absence of access controls. diff --git a/2019/en/src/0xa2-broken-authentication.md b/2019/en/src/0xa2-broken-authentication.md index cf495feca..d0008e004 100644 --- a/2019/en/src/0xa2-broken-authentication.md +++ b/2019/en/src/0xa2-broken-authentication.md @@ -72,7 +72,7 @@ within a few minutes. **Code review** will help to identify authentication issues. **Automated tests** are useful to test the implementation against automated attacks such as -brute-force and credential stuffing. +brute-force and credential stuffing. **Manual tests** will help to identify this issue, by sniffing the traffic and understanding the authentication/authorization workflows. Another method is checking for tokens which can be used to authenticate into the API, JWT tokens are commonly used but can also be easily decrypted, so in reverse we can encypt a JWT token with enumerated information to access the API. ## References diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md index 0e8902f6c..6729fc3b5 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/2019/en/src/0xa3-excessive-data-exposure.md @@ -45,7 +45,7 @@ the site. ## How to Detect -Excessive data exposure is better detected by **manual** means. Mock data can be +Excessive data exposure is best detected by **manual** means, by simply scanning the responses from the API and looking for any sensitive information or variables that can be enumerated. Mock data can be used to automate some testing. ## References diff --git a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md index 48f129e00..f3d89b87d 100644 --- a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md @@ -57,9 +57,8 @@ errors. ## How to Detect -Typically it requires **automated tools** to simulate high workloads. -**Scanners** usually provide such features, highlighting the lack of resources -and rate limiting. Scanners are commonly used during **pentesting**. +**Scanners** usually provide features to simulate large workloads, highlighting the lack of resources +and rate limiting built in, but this can also be found through automated tools that, similar to scanners, lest the pentester generate large customs workloads to overwhelm the API. Scanners are commonly used during **pentesting**. ## References