Web-based APIs can, for the most part, be testing using this guide. Some elements are naturally client-side and therefore irrelevant to API testing.

I suggest that we create an article in section 3 or 4.1 that talks about how the guide can be used for API testing.

I further suggest that we review the existing articles to ensure that the language used is appropriate for web app and APIs alike, and determine where any additions might be needed where testing for the same issue on an API involves a different process.

I figured I'd contribute an initial draft of the Host Header Attack, and a pull request has been created.

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Should be covered by: #57

Someone should just do a sanity check.

• Sanity check

Is your feature request related to a problem? Please describe.
The project lacks PR checks where there are no requirements and no baseline checks for accepting them, which could lead to unintentional merges.

Describe the solution you'd like
Setup a CI tool (Travis, Circle) based on what works best with the project, ensuring the availability of a linter on top of it to ensure that the best practices are being followed.

More dangers than any problems this test might find, are the ones it's left out of scope (e.g. websites without MFA, or MFA without verier impersonation resistance, etc). The most expensive security oversight after malware is the people.

There needs to be a prevalent explanation to guide users that OWASP is only going to address less than half of their problems, and they need to pay serious consideration to design decisions and overall security effectiveness - not just web vulns.

We all know this, but users of this guide are almost certainly unaware of the other things they need to be thinking about. We owe it to them to point these out (if not also add some tests for them: for example - google-authenticator is useless if a phishing site proxies stolen credentials in real time, and 2FA in general is pointless for transactions in the face of malware, etc.)

No description, website, or topics provided. I think we need them.

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

I have found that the repository is lacking issues and PR templates in order to make things smoother for contributors, and for reviewers to better understand the work at hand.

#33 was merged without review and contains numerous errors or items which should be fixed/tweaked. Including (but not necessarily limited to):

• Typos: Sate vs. State when elaborating on the acronym REST. moethods vs methods, reponses vs responses, etc.
• Sentence fragments:

  • Web application APIs following the REST style that called REST API.

  • REST APIs using URIs (Uniform Resource Identifires) to access resources.

  • HTTP headers are used in request and reponses.

  • etc
• Formatting
• Title caps
• Reference consistency (86 or 96?)

  RFC3886 URI - https://tools.ietf.org/html/rfc3986

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Hi all! There's a couple of half-completed translations for V4 on crowdin https://crowdin.com/project/owasp-testing-guide-40, should anybody continue translation or would be better to begin with V5 when it comes out?

New content proposed for the input validation section of OWASP

Please let me know your thoughts

Thanks
J./

E.g.
in the DOM as variables
WebSQL
etc

May require a rename... perhaps "Insecure Client-Side Storage of Sensitive Data"

Hi @kingthorin @MatOwasp ,

I have been read about CSRF at OWASP-Testing-Guide-v4
I realized that not cover some techniques to exploit CSRF in modern web application like json. So can I write and commit my test case about this topic? @

Is your feature request related to a problem? Please describe.

This task arose out of issues and #65 #10, specifically this comment #10 (comment)

There have been a lot of discussions regarding changes to where images are stored, how links should be handled, and file names. As the discussion, we should have a template to be able to:

1. Visualize all the proposals in a more concrete manner
2. Make it easier to either create new articles or fix old ones

Describe the solution you'd like

The acceptance criteria of this task is to have template files that show:

1. A file providing a template for the a test case (example: for Section 4), ready to use such that if someone was writing a new article (like the infrastructure as code for issue #15), they can copy-paste that template and modify simply by adding content and replacing the fake text with real text.
2. An images folder, with an image in it. We mentioned we want a convention for images, so the template should also demonstrate that convention.

Optional:

• I propose the templates be in their own folder, similar to the OWASP's MTSG project. https://github.com/OWASP/owasp-mstg/tree/master/Templates
• If the template itself will look confusing if we put explanations, we could put another file justifying our reasoning for each element in the template. (For example, staying away from spaces to avoid having to URL encode hyperlinks.)
• The other option is to have lots of explanations built into the template itself, but we have to be sure that people don't accidentally copy-paste the template explanations into their real articles. The example I can think of for a "template" like that is the configuration file for a big system like Apache Cassandra - https://github.com/cassandra-rb/cassandra/blob/master/conf/1.2/cassandra.yaml - where there's lots and lots of comments for each line of parsed content. I'm just putting this out as an option, but I greatly prefer having a very small template with the MINIMAL content. When you have large templates, people think that the article itself also has to be large, and for some emerging or very focused fields of web app testing, that probably isn't the case.

Restored broken links in the content page markdown files under each of the testing categories in section 4.

As more and more (web) applications are shipped as containers or based on IaC, I think we should add a section on the specifics testing IaC configurations/systems and container (e.g., Docker) setups. It needs to be decided how much into the details we want to go (e.g., this could be a rather high-level section on best practices or multiple sections discussing the details).

Cheers,
Achim

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Web application integrating external services must be tested for well-known vulnerabilities caused by misconfigurations.

• Amazon AWS bucket service: ...
• Social media profile link validation: ...
• CloudFlare / CDN service: ...
• Unclaimed CNAME domains (DNS?): ...
• ...

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Windows Defender reports the following when downloading the ZIP file:

Threat detected: Backdoor:PHP/Chopper.B!dha
Alert level: Severe
Date: 7/17/2019 3:17 PM
Category: Backdoor
Details: This program provides remote access to the computer it is installed on.

Affected items:

containerfile: \OWASP-Testing-Guide-v5-master.zip

file: \OWASP-Testing-Guide-v5-master.zip->OWASP-Testing-Guide-v5-master/document/4 Web Application Security Testing/4.11 Business Logic Testing/4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009).md

webfile: \OWASP-Testing-Guide-v5-master.zip|https://codeload.github.com/OWASP/OWASP-Testing-Guide-v5/zip/master|pid:4256,ProcessStart:132078676377382571

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Multiple questions:
I don't see any activities whole of 2018. Is this project still in progress?
Any place we can keep a track on roadmap?
I am interested in contributing to various sections, just a standard pull request or do you want anything else there is no guideline referenced anywhere?

Note This section is very long, tackling this issue should be broken in to multiple pull requests to make review/merge easier on everyone. (Consider 3 PRs with 6 pages each? Maybe 4 PRs?)

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Is your feature request related to a problem? Please describe.
The project lacks a Project and Milestones in order to keep track of the issues, set timely goals, and push the project forward in a planned manner.

Describe the solution you'd like
Create a Project and Milestones based on what the project needs as achievements with their corresponding issues.

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Describe the issue
The (external) links to the tools CAT and TamperFox on the page https://github.com/OWASP/OWASP-Testing-Guide-v5/blob/master/document/4%20Web%20Application%20Security%20Testing/4.2%20Information%20Gathering/4.2.6%20Identify%20application%20entry%20points%20%28OTG-INFO-006%29.md are outdated and currently generate 404 error on the external sites they point to.

Specifically, at the bottom of the page:
"Intercepting Proxy:"

• CAT
  "Browser Plug-in:"
• Tamper Data for Firefox -

Suggestions and Observations:
I think Tamper Data died off when Mozilla changed the plugin (e.g. the Kali Linux courses point to outdated versions of Firefox+the plugin). There is a similar plugin https://github.com/Pamblam/Tamper-Data-for-FF-Quantum / https://addons.mozilla.org/en-US/firefox/addon/tamper-data-for-ff-quantum/

There is a Tamper for Chrome https://github.com/google/tamperchrome , but I haven't tried it.

I couldn't find out what happened to the "CAT" tool, nor have I used to to be able to offer ideas of replacements or what it may have been renamed / spun off to.

Is your feature request related to a problem? Please describe.
The file names contain spaces and are not suitable for proper linking in the documents.

Describe the solution you'd like
Create a general rule and refactor the files to a certain naming convention

Is your feature request related to a problem? Please describe.
There was a comment made on pull request #57 about merge strategy being "squash" we should allow the tooling (Github) handle that so we don't need waste time on comments like that.

The comment - #57 (comment)

Describe the solution you'd like
Set the project to enforce merge strategy upon merge of pull requests

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

https://cwe.mitre.org/data/definitions/502.html

A good article about it.

Is your feature request related to a problem? Please describe.
Contributors don't have any proper guidance, how to present their work, nor what are the best practices for their PRs

Describe the solution you'd like
Add a CONTRIBUTING.md specifying how to contribute, how to setup their environment, expected results, etc.

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Describe the issue

1. Update document 4.3 Testing for configuration management.md with new content 4.3.10 Test for subdomain takeover (OTG-CONFIG-010)
2. Align formatting of 4.3 Testing for configuration management.md headers

Guidance, to be added to section 5 (reporting), on how a tester can write programmatic test cases as a form of output, that developers can re-run to determine if an issue has been fixed.

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

In follow-up to: #49 there are some outstanding items to be addressed.

Source ref: https://github.com/OWASP/OWASP-Testing-Guide-v5/blob/master/document/4%20Web%20Application%20Security%20Testing/4.8%20Input%20Validation%20Testing/4.8.18%20Testing%20for%20Host%20Header%20Injection%20(OTG-INPVAL-018).md

First paragraph:

A web server commonly hosts several web application on the same IP address

applications plural (on the first occurrence)

referring to each applications via

application (singular here)

to the target virtual host of the value supplied in the Host header

to the target virtual host based on the value supplied in the Host header

For the whole second chunk of this paragraph:

"Without proper validation of the header value, the attacker can supply invalid input to cause the web server: to dispatch requests to the first virtual host on the list without proper validation of the HTTP request Host header value, cause a redirect to an attacker-controlled domain, perform web cache poisoning, or manipulate password reset functionality."

Second paragraph:

not to an internal virtual hosts that

host singular

Third section:

X-Forwarded Host header Bypass heading should be title caps Header.

Producing the following client-side output.

Potentially producing client-side output such as:

• "wikilinks" during migration the OWASP Mediawiki links were tagged "wikilink" these needs to be converted to proper absolute URLs.
  • Unless the wikilink is to content within the OTG, in which case it should be the proper new github relative URL (URL Encoded).
• Foot notes/references should use standard in-line links. (One of the first two here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links)
  • If a foot note is really required use numeric reference type tags, ex: Content ref: [[1]] Footer ref: [1]: http://example.org
• Images need to be saved to <chapter (or sub-section)>/images/<image.ext> and linked relatively like images/image.ext. (Images in a folder along side the relevant content. [Even if that means duplicates in the overall project.])
• Any spurious / terminating lines, etc. need to be removed and appropriately fixed up for markdown (it's likely a spot that requires a double line-feed prior to an image or other element).
• In some cases (due to the source of the text) there are broken apostrophes ' they should just be restored.
• HTML entities need to be properly handled.
  • Occurrences of \$ should become $
  • At symbols @ should become @
• Headers should be properly formatted with leading # (hashtags) per: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#headers

Hi @MatOwasp,

I just read about NEW TESTS TO WRITE and OWASP testing guide v4. And I did not see any topics about Testing subdomain take over techniques. Can we add a topic about this attacking case?