Deploy the generated website via GitHub Actions

README.md

@@ -1 +1 @@
-Website last update: 2024-08-29 at 06:57:06.
+Website last update: 2024-08-29 at 07:02:02.

cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html

@@ -2762,6 +2762,10 @@ <h4 id="bad-questions">Bad Questions<a class="headerlink" href="#bad-questions"
 <td>What is the make and model of your first car?</td>
 <td>Fairly small range of likely answers.</td>
 </tr>
+<tr>
+<td>What is your nickname?</td>
+<td>This could be guessed by glancing through social media posts.</td>
+</tr>
 </tbody>
 </table>
 <p>Additionally, the context of the application must be considered when deciding whether questions are good or bad. For example, a question such as "What was your maths teacher's surname in your 8th year of school?" would be very easy to guess if it was using in a virtual learning environment for your school (as other students probably know this information), but would be much stronger for an online gaming website.</p>
@@ -2789,7 +2793,7 @@ <h4 id="restricting-answers">Restricting Answers<a class="headerlink" href="#res
 <li>Common strings such as "123" or "password".</li>
 </ul>
 <h4 id="renewing-security-questions">Renewing Security Questions<a class="headerlink" href="#renewing-security-questions" title="Permanent link">&para;</a></h4>
-<p>If the security questions are not used as part of the main authentication process, then consider periodically prompting the user to review their security questions and verify that they still know the answers. This should give them a chance to update any answers that may have changed (although ideally this shouldn't happen with good questions), and increases the likelihood that they will remember them if they ever need to recover their account.</p>
+<p>If the security questions are not used as part of the main authentication process, then consider periodically (such as when they are changing their passwords after expiration) prompting the user to review their security questions and verify that they still know the answers. This should give them a chance to update any answers that may have changed (although ideally this shouldn't happen with good questions), and increases the likelihood that they will remember them if they ever need to recover their account.</p>
 <h3 id="system-defined-security-questions">System Defined Security Questions<a class="headerlink" href="#system-defined-security-questions" title="Permanent link">&para;</a></h3>
 <p>System defined security questions are based on information that is already known about the user. The users' personal details are often used, including the full name, address and date of birth. However these can easily be obtained by an attacker from social media, and as such provide a very weak level of authentication.</p>
 <p>The questions that can be used will vary hugely depending on the application, and how much information is already held about the user. When deciding which bits of information may be usable for security questions, the following areas should be considered:</p>

cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html

@@ -4005,7 +4005,7 @@ <h3 id="malformed-img-tags">Malformed IMG Tags<a class="headerlink" href="#malfo
 <p>(Originally found by Begeek, but it was cleaned up and shortened to work in all browsers)</p>
 <h3 id="fromcharcode">fromCharCode<a class="headerlink" href="#fromcharcode" title="Permanent link">&para;</a></h3>
 <p>If the system does not allow quotes of any kind, you can <code>eval()</code> a <code>fromCharCode</code> in JavaScript to create any XSS vector you need:</p>
-<div class="highlight"><pre><span></span><code><span class="p">&lt;</span><span class="nt">a</span> <span class="na">href</span><span class="o">=</span><span class="s">&quot;javascript:alert(String,fromCharCode(88,83,83))&quot;</span><span class="p">&gt;</span>Click Me!<span class="p">&lt;/</span><span class="nt">a</span><span class="p">&gt;</span>
+<div class="highlight"><pre><span></span><code><span class="p">&lt;</span><span class="nt">a</span> <span class="na">href</span><span class="o">=</span><span class="s">&quot;javascript:alert(String.fromCharCode(88,83,83))&quot;</span><span class="p">&gt;</span>Click Me!<span class="p">&lt;/</span><span class="nt">a</span><span class="p">&gt;</span>
 </code></pre></div>
 <h3 id="default-src-tag-to-get-past-filters-that-check-src-domain">Default SRC Tag to Get Past Filters that Check SRC Domain<a class="headerlink" href="#default-src-tag-to-get-past-filters-that-check-src-domain" title="Permanent link">&para;</a></h3>
 <p>This attack will bypass most SRC domain filters. Inserting JavaScript in an event handler also applies to any HTML tag type injection using elements like Form, Iframe, Input, Embed, etc. This also allows the substitution of any relevant event for the tag type, such as <code>onblur</code> or <code>onclick</code>, providing extensive variations of the injections listed here:</p>