All the links under Related Attacks, Related Vulnerabilities, Related Controls and Related Technical Impacts in Password Plaintext Storage article result in 404 errors

I read more and more articles about the dangers of sim swapping. Would be nice to have some guidelines on how to prevent such attacks.

Example article https://www.vice.com/en_us/article/pke9zk/paypal-and-venmo-are-letting-sim-swappers-hijack-accounts

I had tested them all 12d ago after our last round of changes. Since then there was another set of changes 5days ago and they all 404 now https://github.com/OWASP/www-community/commits/master/pages/initiatives

On the CSRF page (https://owasp.org/www-community/attacks/csrf), the link to the CSRF Prevention Cheat Sheet under the How to Prevent CSRF Vulnerabilities heading is broken. It should point to https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.

Broken links can be found on https://owasp.org/www-community/attacks/xss/

Under the Related Security Activities heading, several links are broken

• Both links for OWASP Development Guide
• Phishing - should be https://wiki.owasp.org/index.php/Phishing ?
• Data Validation - should be https://wiki.owasp.org/index.php/Data_Validation ?
• OWASP Code Review Guide & Reviewing Code for Cross-site scripting - Goes to a migration landing page

Similarly under the References section, the following links are broken:

• Data Validation
• Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001) - should be https://wiki.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) ?
• Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002) - should be https://wiki.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) ?
• Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003) - should be https://wiki.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) ?
• How to Build an HTTP Request Validation Engine (J2EE validation using OWASP’s Stinger)
• http://code.google.com/p/doctype/wiki/ArticlesXSS
• https://owasp.org/www-community/attacks/xss/XSS_Filter_Evasion_Cheat_Sheet

Also under References, this link should be updated

• http://www.cgisecurity.com/articles/xss-faq.shtml -> https://www.cgisecurity.com/xss-faq.html

Hi there, I was taking a look at some of these documents and I noticed that many of them use gendered pronouns, most of which are he/him/his. The OWASP Mobile Security Testing Guide has guidelines for pronoun use: OWASP/owasp-mastg#1586 I think that these should be adopted here, and existing pronoun uses audited.

In the "Threat Agent Factors" chapter the "Skill Level" ratings are inverted:

Expected:

No technical skills (9), some technical skills (6), advanced computer user (5), network and programming skills (3), security penetration skills (1)

Presented:

No technical skills (1), some technical skills (3), advanced computer user (5), network and programming skills (6), security penetration skills (9)

https://github.com/OWASP/www-community/blob/master/pages/CRV2_AppThreatModeling.md

Contains a bunch of HTML based tables that need attention. They did not auto-migrate well and at a certain point break the rendering of the majority of the page.

Before it's defaced or used for some sort of phishing campaign. (Or set it to only editable by admins.)

The page https://owasp.org/www-community/Types_of_Cross-Site_Scripting that contains references to other types of XSS such as Stored XSS, reflected XSS and DOM based XSS all return 404 for the page https://owasp.org/www-community/DOM_Based_XSS, etc

The correct page seems to be at https://owasp.org/www-community/attacks/DOM_Based_XSS
Similarly for other types.

The link
[OWASP XSS Prevention Cheat Sheet]
(XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet "wikilink")
is redirecting to this page,
https://owasp.org/www-community/attacks/xss/XSS_/(Cross_Site_Scripting/)_Prevention_Cheat_Sheet
but should be going to this page:
https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet

Hyperlink for OWASP Top Ten Project is redirecting to 404 page, i guess the url is broken

The link on this page (https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks) for the www-community post "Slow Down Online Guessing Attacks with Device Cookies" should lead to https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies but instead leads to https://owasp.org/www-community/controls/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies, which returns a 404.

I've been maintaining this page:

https://github.com/OWASP/www-community/blob/master/pages/Source_Code_Analysis_Tools.md

and I notice that this page has a list of SAST tools too:

https://github.com/OWASP/www-community/blob/master/pages/controls/Static_Code_Analysis.md

This seems redundant, hard to maintain. I suggest that the list of tools be maintained on the 1st page above, and the 2nd page simply reference the 1st. To me the 2nd page should simply describe what Static Code Analysis IS.

Hi all,

When user visits "Xss in subtitle" page, an alert window will be pop-up.
The URL: https://owasp.org/www-community/attacks/Xss_in_subtitle

I've found a way to bypass certain filters which implement the following behaviour: The filter checks everything between opening and closing or opening and opening brackets. A whitelist is checked against the HTML tag as well as every attribute found within the brackets. Whenever an attribute is not whitelisted the filter will block the input. Closing tags are detected as soon as a slash is found between both brackets. As they aren't considered to contain malicious attributes they are always permitted.

Most HTML tags are opened and closed like this:
<p style="color:blue;">Text</p>
Normally closing tags don't contain any attributes. I found that some filters skip checking for further attributes as soon as they see a slash as they expect to handle a closing tag. Thus it is possible to inject the following JavaScript:
<img src="fail.jpg" / onerror="alert('XSS')"> while <img src="fail.jpg" onerror="alert('XSS')"> gets blocked. The execution of the injected JavaScript has been verified in Firefox 68.9.0 ESR and Chromium 80.0.3987.162. A demonstration can be found in the following video: https://www.youtube.com/watch?v=KBOYJQ45k00

I think this is something which should be considered to be added to the XSS Filter Evasion Cheat Sheet.

Receiving objects: 100% (3022/3022), 4.36 GiB | 25.37 MiB/s, done.

That's going to prevent community contribution in some cases. Even on half-gig service that just took me a few minutes. People with lesser service just won't bother in the future.

On this page: https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
it says:

![<File:NFA.png>](NFA.png "File:NFA.png")

Instead of showing the image of the Automaton.

##Hey. I apologize for my poor English.
I'm trying to intercept the traffic of the system process "SYSTEM (pid 4)", but I can not do this on my computer. Therefore, I use the MITM attack method, redirect the traffic of interest to owasp through my router using the iptables rule:
iptables -t nat -A PREROUTING --dst 10 * .19. ***. 119 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.93
where local 192.168.1.93 is the IP and OWASP zap port, 10*.19.***.119 is the recipient address of the HTTPS packets that I need modify the packets in WASP and forward to 10*.19.***.120: 443
10*.19.***.120:443, 10*.19.***.119:443- is HTTPS ssl server port


But I get an error in the browser.
PS: owasp certificate was imported into the system.

RUS description of trouble
Привет. Прошу прощения за мой плохой английский.
Я пытаюсь перехватить трафик системного процесса "SYSTEM (пид 4)", но не могу этого сделать на своём компьютере. Поэтому я использую метод атаки MITM, перенаправляю в owasp интересующий меня траффик через мой роутер используя iptables правило:
iptables -t nat -A PREROUTING --dst 10*.19.***.119 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.93:443
где локальный 192.168.1.93:443 - IP и порт OWASP zap, 10*.19.***.119 - адрес получателя ХТТПС пакетов, которые мне нужно перехватить и отправить на 10*.19.***.120:443
10*.19.***.120:443, 10*.19.***.119:443 - это HTTPS ssl server port
Но я получаю ошибку в браузере.
ПС: сертификат owasp был импортирован в ситеме.

I am reading this this page and I cannot see the control flow graph image. I realize that the image is not exist. I dont know how the image look like so I can't modify it and make a PR, so I make this issue and hope someone can fix it out.

#``

In www-community/static_code_analysis.md, there are multiple references to Wogerer, 2015. However, the referenced article can't be found as a link on the page.

The article for "CRLF Injection" (https://github.com/OWASP/www-community/blob/master/pages/vulnerabilities/CRLF_Injection.md) needs some editing in this broken sentence:

If an attacker managed to place a CRLF then can then inject some sort of read programmatic method to the file.

https://wiki.owasp.org/index.php/Get_Started_with_OWASP_Bug_Bounty

@mikemccamon or @hblankenship any thoughts on where this should be located/linked, etc?

The image Fake-text.png is broken in https://github.com/OWASP/www-community/blob/master/pages/attacks/Content_Spoofing.md#risk-factors

_{Edited: by @kingthorin 2020-06-12, to use original instead of fork paths.}

Regarding www-community/pages/OWASP_Application_Security_FAQ.md
Under the Where can I try out my testing skills.... heading is this link: http://www.hackingzone.org/sql/index.php which redirects to a dead page.

Per discussion on slack the GSoC related content* should be migrated to this repo.

*Ex:

• www.owasp.org/index.php/GSoC*_Ideas
• https://www.google.com/search?q=gsoc+site%3Aowasp.org&oq=gsoc+site%3Aowasp.org

My current plan is to create a gsoc folder within https://github.com/OWASP/www-community/tree/master/pages

_{Feel free to assign this issue to me.}

This content should be migrated as an "attack". Some of the "discussion" content should also be added as a note/update.

https://wiki.owasp.org/index.php/OWASP_WS_Amplification_DoS_Project

www-community/_data/tools.json cites "misterscanner.com" at the top most position of the table.
https://owasp.org/www-community/Vulnerability_Scanning_Tools

This website does not offer free scanning services.
The site redirects to Paypal's sandbox.paypal.com URL when you select the 6USD yearly plan. ( this website is used for development purposes)
All other pricier plans complete the payment process and charge.
After paying for a plan, the website immediately starts a "scan" on the selected domain without any DNS ownership validations. The results of this scan can't be found anywhere on the website and we never receive an email with the attached PDF of the results.
The chat function with "Alex" and email option never respond to our requests for help.
The website and email service are hosted on GoDaddy.

Please review this information and take appropriate action.

Buffer Overflow

All links return 404.

There seems to be 2 different definitions for DOM-based XSS

• https://owasp.org/www-community/attacks/DOM_Based_XSS
• https://owasp.org/www-community/Types_of_Cross-Site_Scripting
  First one reads

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

And the second one

DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Consider a case where SPA retrieves data from json api, and insecurely inserts the data on the page using innerHTML. It looks like it would fit the first definition of DOM-based XSS, but not the second.

Many sources seem to define DOM-based xss in a way that my example would fall under it. Examples:

• https://dl.acm.org/doi/abs/10.1145/2508859.2516703

DOM-based XSS [16], a vulnerability class subsuming all Cross-site Scripting problems that are caused by insecure handling of untrusted data through JavaScript.

• https://dl.acm.org/doi/10.5555/2671225.2671267

In contrast to the server-side variants of XSS, namely reflected and persistent, the term DOM-based Cross-Site Scripting (or DOM-based XSS) subsumes all classes of vulnerabilities which are caused by insecure client-side code

• https://research.google/pubs/pub49950/
  Context being DOM-based XSS attacks:

For readability, the example in Fig. 1 is artificially simple, which may convey a false impression that XSS vulnerabilities are not difficult to detect or mitigate. In reality, the information flow from XSS sources to sinks can be extremely complex and often goes through servers and databases
It is a typical client-side XSS vulnerability, aka. DOM-based XSS.

• https://dl.acm.org/doi/10.1016/j.cose.2011.12.004

We do not address DOM-based (Type III) XSS attacks, where trusted client-side JavaScript permits the injection of untrusted content in violation the web application’s security policy

OWASP XSS Prevention Cheat Sheet page not available

https://owasp.org/www-community/Application_Threat_Modeling contains link to https://owasp.org/www-community/Threat_Modeling_Outputs which is 404.

The entropy recomendations for the Insufficient Session-ID Length vulnerability state that

Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier.

Since this is a non-obvious claim and the reasoning behind it elludes me, this claim should be backed up by a source link and/or some explanation.

Was going through pages, found plenty of broken references. Ran a broken URL checker against the website, found a lot of broken URLs. Fixed some of them in #290 . Some URLs remain broken:

https://support.google.com/mail/forum/AAAAK7un8RU3J3r2JqFNTw/discussion/?hl=en&gpf=d/topic/gmail/3J3r2JqFNTw/discussion
https://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2
http://www.php-security.org/downloads/rips.pdf
http://www.seclab.tuwien.ac.at/papers/pixy.pdf
http://w2spconf.com/2010/papers/p27.pdf
https://www.codemagi.com/blog/post/194
https://www.itu.int/rec/T-REC-X.690-200811-I/en
https://www.ietf.org/id/draft-ietf-websec-key-pinning-09.txt
https://github.com/andresriancho/w3af/blob/master/plugins/grep/csp.py
http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html
http://www.webapptest.org/ms-access-sql-injection-cheat-sheet-EN.html
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=77
http://www.ruxcon.org.au/files/2008/Attacking_Rich_Internet_Applications.pdf
http://yehg.net/lab/pr0js/files.php/inspath.zip
http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip
http://www.comptechdoc.org/independent/web/cgi/ssimanual/ssiexamples.html
http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm
http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf
http://archives.neohapsis.com/archives/bugtraq/2002-05/0118.html
http://hacker-eliminator.com/trojansymptoms.html
http://www.microsoft.com/technet/security/bulletin/MS00-078.mspx
https://www.checkmarx.com/Demo/XSHM.aspx
https://blog.watchfire.com/wfblog/2008/06/javascript-code.html
http://shlang.com/netkill/netkill.html
https://cirt.net/code/nikto.shtml
https://addons.mozilla.org/en-US/firefox/addon/heartbleed-checker/
https://www.ecrimelabs.com/tools/webroot/WebRoot.txt
https://www.cs.rice.edu/~scrosby/hash/slides/USENIX-RegexpWIP.2.ppt
https://www.checkmarx.com/NewsDetails.aspx?id=23&cat=3
https://owasp.org/index.php/Dhiraj_Mishra
http://puzzlemall.googlecode.com/files/Session
https://owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf
http://windows.stanford.edu/docs/IISsecchecklist.htm
http://www.net-security.org/dl/articles/php-file-upload.pdf
http://www.windowsitpro.com/Files/18/27072/Webtable_01.pdf
https://www.imperva.com/404?aspxerrorpath=/application_defense_center/glossary/forceful_browsing.html
http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html
https://blog.shapesecurity.com/heartbleed-bug-places-encrypted-user-data-and-webservers-at-risk
https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf
http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx
http://www.digitaldwarf.be/products/mangle.c
http://projects.info-pull.com/mokb/
http://www.bonsai-sec.com/en/research/untidy-xml-fuzzer.php
https://support.snyk.io/snyk-cli/how-can-i-set-a-snyk-cli-project-as-open-source
http://www.rubcast.rub.de/index2.php?id=1009
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
http://aeditor.rubyforge.org/ruby_cplusplus/index.html
https://owasp-skf.gitbook.io/asvs-write-ups/filename-injection
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
https://blog.48bits.com/2010/09/28/iis6-asp-file-upload-for-fun-and-profit/
http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/
http://www.bindshell.net/tools/odysseus
http://www.ntobjectives.com/products/firewater/
http://home.intekom.com/rdawes/exodus.html
http://www.wastelands.gen.nz/odysseus/index.php
http://www.webcohort.com/web_application_security/research/tools.html
http://www.rsasecurity.com/standards/ssl/basics.html
http://palisade.plynt.com/issues/2005Aug/page-tokens/
http://www.microsoft.com/mspress/books/toc/5612.asp
http://www.seczone.cn/2018/06/27/codesec源代码安全检测平台/

If anyone wants to go through these, grep --color=always -nr -Ff broken_urls_left.txt|grep --color=always -v "broken_"|sort will show where those URLs are specifically (might miss some of these, though). Could probably also find a lot of broken internal references by looking for "wikilink".

Since browsers stop sending cookies across origins, is this a time to retire the CSRF chapter? Or put a big IF condition for the attack narrowing it down to request handlers whose authentication handlers issued a SameSite=None attribute with their session cookie?

https://web.dev/samesite-cookies-explained/

(I guess every vulnerability, not just CSRF could benefit from formalizing the conditions on their context. E.g., overly permissive CORS would be conditional on the presence of the respective ACAO response AND exposing sensitive data with a browser's platform authentication. The missing HTTPOnly attribute in cookies is dangerous in a context of a malicious script such as a third-party tracker).

See the latest OWASP Testing Guide article on how to test for the various kinds of XSS vulnerabilities.

Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)
Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)
Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)

all of those links go to 404s.

In this article:

https://github.com/OWASP/www-community/blob/master/pages/vulnerabilities/Using_freed_memory.md

There is a hyperlink to write-what-where condition.

Such an article does not exist.

I just finished dealing with auto-migrated issues for this article, it could definitely use some content updates:
https://github.com/OWASP/www-community/blob/master/pages/HttpOnly.md it still talks about old versions of IE and Opera.

This article includes an extensive table that needs re-working after the auto-migration as well (which I did not tackle).

Is Opera even relevant in 2020? Do we still care about IE with Edge/Edge Chrome?

Link OWASP SonarQube Project is broken.
It has even docker image, but due to broken links - it is very unclear how maintained this project is.

The post with title 'Application Threat Modeling' contains a broken reference link.
The URL of the reference is https://owasp.org/www-community/Threat_Modeling_Outputs whose corresponding page does not exist.

This will be nice if you add here -> https://github.com/OWASP/www-community/blob/master/pages/attacks/Format_string_attack.md

int a=1,b=2,c=3;
printf("c: %3$d b: %2$d a: %1$d",a,b,c) - this describe how to manipulate parameters co compres payload
printf("%1$1000000d %2$n \n",a,b); - this show how to expand format output for memory overflow

_{Edited a few minor typos}

On page https://owasp.org/www-community/attacks/csrf
If you click on links most of them are not working like below link
https://owasp.org/www-community/attacks/Tokenizing

The example code

Select your language:

<select><script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script></select>

Is no longer vulnerable on most modern browsers since document.location.href is URL encoded by default. The example should be updated to reflect that decoding is required for the attack to work as described.

There is a small grammar mistake in the CORS attack page at this link https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny

Issue: the grammar mistake is in this sentence "The header can contains either a [...]"
Suggested fix: remove "s" from "contains"

In the page:

https://github.com/OWASP/www-community/blob/master/pages/attacks/Format_string_attack.md

There is an example of a format string attack.
The example is:

int main (int argc, char **argv) {
char buf [100]; int x = 1 ;
snprintf ( buf, sizeof buf, argv [1] ) ;
buf [ sizeof buf -1 ] = 0;
printf ( “Buffer size is: (%d) \nData input: %s \n” , strlen (buf) , buf ) ;
printf ( “X equals: %d/ in hex: %#x\nMemory address for x: (%p) \n” , x, x, &x) ;
return 0 ; }

And the explanation is that the %x or %s gets expanded in the printf function.
This is completely wrong.
The crash happens in the line of snprintf , NOT in the printf line.

The line printf ( “Buffer size is: (%d) \nData input: %s \n” , strlen (buf) , buf ) ; is safe!
And printf("my string is %s", "%s%s%s%s%s%s%s") will NOT cause a crash

In the page https://owasp.org/www-community/Source_Code_Analysis_Tools There is no comment about the architecture of graudit.

It let think that graudit works on any platform. Actually it is more destined to linux users. It does not compile on windows with no cygwin and 80% of the code is bash script.

So I suggest to add "linux" in the tab architecture of the array of the line graudit.

I just did a git pull and git attempted to create the following files, I don't actually see them in the repo (GitHub web view) or my file system, but it seems likely there's an issue somewhere (git knows/believes they are there):

 create mode 100644 "assets/files/migrated/02_INGENIER\303\215A_SOCIAL.pdf"
 create mode 100644 "assets/files/migrated/04_OWASP_LatamTur2012_M.Mart\303\255nez.pdf"
 create mode 100644 "assets/files/migrated/04_OWASP_TOP10_como_base_para_Inspecci\303\263n_de_C\303\263digo.pdf"
 create mode 100644 "assets/files/migrated/1st_URUGUAY_OWASP_DAY_-_Mateo_Mart\303\255nez.pdf"
 create mode 100644 "assets/files/migrated/2011\353\205\2046\354\233\224_OWASP_\354\213\234\355\201\220\354\226\264\354\275\224\353\224\251\352\267\234\354\271\231_v2_KOR.pdf"
 create mode 100644 "assets/files/migrated/2013-1_C\303\263mo_construir_un_modelo_de_desarrollo_seguro_-_Mateo_Martinez_-_URUGUAY_-.pdf"
 create mode 100644 "assets/files/migrated/2013-3_ZAP_OWASP_-_A_Real_ZAP_Story_-_Mateo_Mart\303\255nez_v0.1.pdf"
 create mode 100644 "assets/files/migrated/2013-4_CAPTCHA_Hacking_T\303\251cnicas_y_herramientas_que_vulneran_sitios_de_la_banca_y_comercio_electr\303\263nico_-_Ricardo_Supo_-_PERU_-.pdf"
 create mode 100644 "assets/files/migrated/2013-5_OWASP-BWA_Hacking_the_Web,_como_aprender_y_practicar_sin_terminar_en_la_c\303\241rcel._-_Felipe_Sanchez_-_CHILE_-.pdf"
 create mode 100644 "assets/files/migrated/2014-abril-3_Innovaci\303\263n_y_emprendimiento.pdf"
 create mode 100644 "assets/files/migrated/5-OWASP-LatamTour2013_(Mateo_Mart\303\255nez).pdf"
 create mode 100644 "assets/files/migrated/\302\277C\303\263mo_lo_Lograron_.pdf"

Edit: To be clear the pull successfully added 100s of other assets and changes without issue, those above just stuck out as strange/problematic.

When looking at the SQL injection related attacks section, it seems that the Interpreter_Injection#ORM_Injection link is broken.

It should be checked or removed.