Does SameSite Provide Sufficient CSRF Defence?

During web security assessments we are often asked: “If we implement the SameSite cookie attribute, will it be enough to protect the application from Cross-site Request Forgery (CSRF) attacks? The short answer is no, primarily due to the implementation mechanism being a client –side control (it is dependent on the browser implementing the cookie attribute). Why the SameSite cookie attribute does not replace a secure Anti-CSRF mechanism: The control is implemented client-side, and is not as secure as a server-side per request-based mechanism. Many frameworks support GET and POST HTTP response methods, by simply changing the request method to GET the cookie would be sent without the additional client-side protection provided by the SameSite attribute. Legacy clients (old web browsers) may not support the SameSite attribute, and therefore ignore the cookie attribute. When is the SameSite Cookie Attribute Useful? In most cases the SameSite cookie attribute should not be depended on as a single line of defence against CSRF attacks. However, if used in conjunction with a secure Anti-CSRF mechanism the SameSite attribute can be used to further mitigate the environment against CSRF attacks.

Read More

What is XSS (Cross-site Scripting)?

Cross-site Scripting (XSS) An overview of the three main types of Cross-site Scripting (XSS) attacks, Reflected, Stored & DOM Based. Introduction This document provides an overview of the three main types of XSS attacks. Giving a clear definition with detailed diagrams explaining clearly how the attack takes place. A useful resource for web developers or web app security assessment companies. What is XSS (Cross-site Scripting) What is XSS? Cross-site scripting also known as XSS is a Client Side attack where code is executed in the victims browser either from injecting JavaScript into a web application and having a victim visit the vulnerable URL. Or, by directly tricking a user into clicking a link with a payload crafted into the URL. The three main types of Cross-site Scripting: Reflected XSS, Stored XSS and DOM Based XSS are documented below. Different Types of XSS Explained Stored XSS Definition Stored XSS, occurs when user supplied input is stored and then rendered within a web page. Typical entry points for stored XSS are: message forums, blog comments, user profiles and username fields. An attacker typically exploits this vulnerability by injecting XSS payloads on popular pages of a site or passing a link to a victim, tricking them into viewing the page that contains the stored XSS payload. The victim visits the page and the payload is executed client side by the victims web browser. Stored XSS is also known as persistent cross-site scripting or persistent XSS. Stored XSS Attack: Basic Example The diagram below assumes the attacker has already discovered a stored cross-site scripting vulnerability on the target web application and has a way of tricking or ensuring the victim will visit the page containing the stored payload. Typical Entry Points for Stored XSS Stored XSS requires user supplied input to be stored by the application (making it persistent) and rendered within the page. The following list identifies some typical locations where Stored XSS vulnerabilities exist: Message Forums Blog Comments Profile page information Admin portals Looking for a manual security assessment? See our Penetration Testing Services page for more details. Typical Attack Vectors for Stored XSS An attacker can execute JavaScript of their choosing on the victims machine, therefore XSS can be used to execute a number of security risks and / or be used in combination with other web vulnerabilities to exploit a higher severity security vulnerability. Redirecting the browser Link placement Hooking browsers – beef (redirecting vulnerable browsers to exploits) Cookie Theft / Session Hijacking Key logging Using XSS to steal CSRF tokens Fake login forms Abusing HTML 5 Cookie Theft Example using Stored XSS The following example uses a vulnerable blog comment system to inject an XSS payload on a popular page often visited by the victim(s). The following XSS payload attempts to load an image from the attackers server with the victims cookie data within the request URL. After a request for the image has taken place the attacker can extract the victims session identifier from the web server log […]

Read More

Local File Inclusion (LFI)

Local File Inclusion (LFI) Local File Inclusion (LFI) explained with examples, and learn how to perform security testing for LFI vulnerabilities. Introduction The intent of this document is to assist with web app security assessments engagements by consolidating research for LFI testing techniques. LFI vulnerabilities are typically discovered during application assessments or penetration testing using the techniques contained within this document. What is a Local File Inclusion (LFI) vulnerability? Local File Inclusion (LFI) allows an attacker to include files on a server through the web browser. This vulnerability exists when a web application includes a file without correctly sanitising the input, allowing and attacker to manipulate the input and inject path traversal characters and include other files from the web server. The following is an example of PHP code vulnerable to local file inclusion.

Read More

LLMNR / NBT-NS Spoofing Attack

LLMNR / NBT-NS Spoofing Attack LLMNR / NBT-NS spoofing attackhow to use LLMNR & NetBIOS poisoning to capture credentials from the network using Kali + Responder.py and how to fix LLMNR & NBT-NS (NetBIOS) spoofing / poisoning attacks. Introduction A LLMNR & NBT-NS Spoofing Attack is a classic internal network attack that still works today, due to low awareness and the fact it’s enabled by default in Windows. This document explains what a LLMNR & NBT-NS attack is, how to use the attack when performing pen testing services and how to secure networks against the vulnerability. [clickToTweet tweet=”Check out the LLMNR Spoofing Guide by @AptiveSec #infosec #pentesting” quote=”Check out the LLMNR Spoofing Guide by Aptive”] What is LLMNR & NetBIOS Name Server Broadcast? When a DNS name server request fails Microsoft windows systems use Link-Local Multicast Name Resolution (LLMNR for short) and the Net-BIOS Name Service (NBT-NS) for fallback name resolution. What’s the issue with LLMNR & Netbios NS Broadcasting? If the DNS name does not resolve, the client performs a unauthenticated UDP broadcast to the network asking if any other system has the name it’s looking for. The fact this process is unauthenticated and broadcasted to the whole network allows any machine on the network to respond and claim to be the target machine. What is a LLMNR / NBT-NS Poisoning Attack? By listening for LLMNR & NetBIOS broadcasts it’s possible to masquerade as the machine (spoof) the client is erroneously trying to authenticate with. After accepting the connection it’s possible to use a tool like Responder.py or Metasploit to forward on requests to a rogue service (like SMB TCP: 137) that performs the authentication process. During the authentication process the client will send the rogue server a NTLMv2 hash for the user that’s trying to authenticate, this hash is captured to disk and can be cracked offline with a tool like Hashcat or John the Ripper (TJR) or used in a pass-the-hash attack. LLMNR and NBT-NS are enabled by default in Windows and with awareness of this attack being fairly low you stand a good chance of being able to gather credentials on an internal network. Leave Responder.py running during an engagement while you’re working other attack vectors. What about Linux & Apple clients, are they Vulnerable? Yes, Linux and Apple clients use a similar protocol called multicast DNS or mDNS for short which listens on TCP: 5353. For more information on mDSN see the mDNS wikipedia page Typical LLMNR / NetBIOS Name Server Attack The diagram below shows the typical scenario for this type of attack where a user mistypes a server name. Step-by-step LLMNR / NBT-NS Poisoning Attack User sends incorrect SMB share address \SNARE01 DNS Server responds with \SNARE01 – NOT FOUND Client performs LLMNR / NBT-NS broadcast Responder tells the client it’s SNARE01 and accepts the NTLMv2 hash Responder sends an error back to the client, so the end user is non the wiser and simply thinks they have the wrong share name Practical […]

Read More
X