Merge pull request #10743 from jsoref/spelling

Spelling

java/ql/src/Frameworks/Spring/Architecture/Refactoring Opportunities/UnusedBean.qhelp

@@ -16,7 +16,7 @@ A bean definition is considered to be used if one or more of the following is tr
 <li>The bean is injected in to a constructor or method of a live bean due to autowiring. This includes
 autowiring by annotation (<code>@Autowired</code> or <code>@Inject</code>), and autowiring configured
 by the autowired attribute within bean configuration files.</li>
-<li>The bean is explictly loaded from a factory bean. It is not always possible to determine when
+<li>The bean is explicitly loaded from a factory bean. It is not always possible to determine when
 this occurs, because factory beans are loaded using a <code>String</code> value, which may contain
 arbitrary values.</li>
 <li>The bean is called reflectively by the Spring framework. For example, if the class is a Spring

java/ql/src/Likely Bugs/Concurrency/DoubleCheckedLockingShared.inc.qhelp

@@ -62,7 +62,7 @@ runtime.
 <p>
 The code above should be rewritten to both use <code>volatile</code> and finish
 all initialization before <code>f</code> is updated. Additionally, a local
-variable can be used to avoid reading the field more times than neccessary.
+variable can be used to avoid reading the field more times than necessary.
 </p>
 <sample src="DoubleCheckedLockingGood.java"/>
 

java/ql/src/Security/CWE/CWE-200/TempDirLocalInformationDisclosure.qhelp

@@ -43,7 +43,7 @@ For example: <code>PosixFilePermissions.asFileAttribute(EnumSet.of(PosixFilePerm
 </example>
 
 <references>
-    <li>OSWAP: <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">Insecure Temporary File</a>.</li>
+    <li>OWASP: <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">Insecure Temporary File</a>.</li>
     <li>CERT: <a href="https://wiki.sei.cmu.edu/confluence/display/java/FIO00-J.+Do+not+operate+on+files+in+shared+directories">FIO00-J. Do not operate on files in shared directories</a>.</li>
 </references>
 </qhelp>

java/ql/src/Security/CWE/CWE-925/ImproperIntentVerification.qhelp

@@ -26,7 +26,7 @@ Otherwise, a third-party application could impersonate the system this way to ca
 
 <recommendation>
 <p>
-In the <code>onReceive</code> method of a <code>BroadcastReciever</code>, the action of the received Intent should be checked. The following code demonstrates this.
+In the <code>onReceive</code> method of a <code>BroadcastReceiver</code>, the action of the received Intent should be checked. The following code demonstrates this.
 </p>
 <sample src="Good.java" />
 </recommendation>

java/ql/src/experimental/Security/CWE/CWE-094/SpringViewManipulation.qhelp

@@ -8,7 +8,7 @@
       including invocation of methods available in the JVM.
     </p>
     <p>
-      An unrestricted view name manipulation vulnerability in Spring Framework could lead to attacker-controlled arbitary SpEL expressions being evaluated using attacker-controlled data, which may in turn allow an attacker to run arbitrary code.
+      An unrestricted view name manipulation vulnerability in Spring Framework could lead to attacker-controlled arbitrary SpEL expressions being evaluated using attacker-controlled data, which may in turn allow an attacker to run arbitrary code.
     </p>
     <p>
       Note: two related variants of this problem are detected by different queries, `java/spring-view-manipulation` and `java/spring-view-manipulation-implicit`. The first detects taint flow problems where the return types is always <code>String</code>. While the latter, `java/spring-view-manipulation-implicit` detects cases where the request mapping method has a non-string return type such as <code>void</code>.
@@ -19,7 +19,7 @@
     <p>
       In general, using user input to determine Spring view name should be avoided.
       If user input must be included in the expression, the controller can be annotated by
-      a <code>@ReponseBody</code> annotation. In this case, Spring Framework does not interpret 
+      a <code>@ResponseBody</code> annotation. In this case, Spring Framework does not interpret 
       it as a view name, but just returns this string in HTTP Response. The same applies to using
       a <code>@RestController</code> annotation on a class, as internally it inherits <code>@ResponseBody</code>.
     </p>
@@ -31,7 +31,7 @@
     </p>
     <sample src="SpringViewBad.java" />
     <p>
-      This can be easily prevented by using the <code>ResponseBody</code> annotation which marks the reponse is already processed preventing exploitation of Spring View Manipulation vulnerabilities. Alternatively, this can also be fixed by adding a <code>HttpServletResponse</code> parameter to the method definition as shown in the example below.
+      This can be easily prevented by using the <code>ResponseBody</code> annotation which marks the response is already processed preventing exploitation of Spring View Manipulation vulnerabilities. Alternatively, this can also be fixed by adding a <code>HttpServletResponse</code> parameter to the method definition as shown in the example below.
     </p>
     <sample src="SpringViewGood.java" />
   </example>

java/ql/src/experimental/Security/CWE/CWE-299/DisabledRevocationChecking.qhelp

@@ -23,7 +23,7 @@ then revocation checking is not going to happen.</p>
 </overview>
 <recommendation>
 
-<p>An application should not disable the default revocationg checking mechanism
+<p>An application should not disable the default revocation checking mechanism
 unless it provides a custom revocation checker.</p>
 
 </recommendation>

java/ql/src/experimental/Security/CWE/CWE-327/UnsafeTlsVersion.qhelp

@@ -3,14 +3,14 @@
 
 <overview>
 <p>Transport Layer Security (TLS) provides a number of security features such as 
-confidentiality, integrity, replay prevention and authenticatin. 
+confidentiality, integrity, replay prevention and authentication. 
 There are several versions of TLS protocols. The latest is TLS 1.3.
 Unfortunately, older versions were found to be vulnerable to a number of attacks.</p>
 
 </overview>
 <recommendation>
 
-<p>An application should use TLS 1.3. Currenlty, TLS 1.2 is also considered acceptable.</p>
+<p>An application should use TLS 1.3. Currently, TLS 1.2 is also considered acceptable.</p>
 
 </recommendation>
 <example>

java/ql/src/experimental/Security/CWE/CWE-470/UnsafeReflection.qhelp

@@ -3,7 +3,7 @@
 
 <overview>
 <p>
-Allowing users to freely choose the name of a class to instantiate could provide means to attack a vulnerable appplication.
+Allowing users to freely choose the name of a class to instantiate could provide means to attack a vulnerable application.
 </p>
 </overview>
 

java/ql/src/experimental/Security/CWE/CWE-502/UnsafeDeserializationRmi.qhelp

@@ -50,7 +50,7 @@ whose methods use only primitive types and strings:
 <sample src="RmiSafeRemoteObject.java" />
 
 <p>
-The next example shows how to set a deserilization filter for a remote object:
+The next example shows how to set a deserialization filter for a remote object:
 </p>
 <sample src="RmiRemoteObjectWithFilter.java" />
 

java/ql/src/experimental/Security/CWE/CWE-665/InsecureRmiJmxEnvironmentConfiguration.qhelp

@@ -6,7 +6,7 @@
 <overview>
 <p>For special use cases some applications may implement a custom service which handles JMX-RMI connections.</p>
 
-<p>When creating such a custom service, a developer should pass a certain environment configuration to the JMX-RMI server initalisation, 
+<p>When creating such a custom service, a developer should pass a certain environment configuration to the JMX-RMI server initialization, 
 as otherwise the JMX-RMI service is susceptible to an unsafe deserialization vulnerability.</p>
 
 <p>This is because the JMX-RMI service allows attackers to supply arbitrary objects to the service authentication 
@@ -41,11 +41,11 @@ For this reason an initialization with a <code>null</code> environment is also v
 
 <p>The first example shows how an JMX server is initialized securely with the <code>JMXConnectorServerFactory.newJMXConnectorServer()</code> call.</p>
 
-<sample src="CorrectJMXConnectorServerFactoryEnvironmentInitialisation.java" />
+<sample src="CorrectJMXConnectorServerFactoryEnvironmentInitialization.java" />
 
 <p>The second example shows how a JMX Server is initialized securely if the <code>RMIConnectorServer</code> class is used.</p>
 
-<sample src="CorrectRMIConnectorServerEnvironmentInitalisation.java" />
+<sample src="CorrectRMIConnectorServerEnvironmentInitialization.java" />
 
 </example>
 

java/ql/test/query-tests/security/CWE-297/UnsafeHostnameVerification.java

@@ -46,7 +46,7 @@ public class UnsafeHostnameVerification {
     private void functionThatActuallyDisablesVerification() {
         HttpsURLConnection.setDefaultHostnameVerifier((name, s) -> true); // GOOD [but detected as BAD], because we only
                                                                           // check guards inside a function
-        // and not accross function calls. This is considerer GOOD because the call to
+        // and not across function calls. This is considerer GOOD because the call to
         // `functionThatActuallyDisablesVerification` is guarded by a feature flag in
         // `testGuardedByFlagAccrossCalls`.
         // Although this is not ideal as another function could directly call