Cross-Site Scripting or XSS is a type of security vulnerability where an attacker gains access to a website and executes a potentially malicious script at the client’s side. This is one of the code injections attacks which can be caused by incorrectly validating user data, which usually gets inserted into the page through a web form or using a hyperlink that has been tampered. This code can be inserted via any client-side coding languages such as JavaScript, HTML, PHP, VBScript.
Why do they occur?
Cross-Site Scripting or XSS attacks occur mostly due to non-delivery of secure codes from the server-side developers. Thus, it is the responsibility of every programmer to provide a security code that can make it hard for attackers to exploit possible security vulnerabilities.
What can an attacker accomplish with XSS?
XSS vulnerability can be used by an attacker to accomplish a set of potential nefarious goals, like –
- Steal ‘session identifier’ – By stealing one’s session id, the attacker can impersonate us and access the application. This can lead to the unauthorized person accessing the potential data.
- URL redirection – URL redirection is the act of redirecting a user to another malicious phishing page to gather sensitive information.
- Run unwanted software – An attacker can also install malware on our computers and other devices. This malware can cause harm to the data which is residing on the device.
Preventing XSS in HTML and PHP
Following are the methods by which we can prevent XSS in our web applications –
- Using htmlspecialchars() function – The htmlspecialchars() function converts special characters to HTML entities. For a majority of web-apps, we can use this method and this is one of the most popular methods to prevent XSS. This process is also known as HTML Escaping.
- ‘&’ (ampersand) becomes ‘&’
- ‘”‘ (double quote) becomes ‘”’
- ” (greater than) becomes ‘>’
- htmlentities() – htmlentities() also performs the same task as htmlspecialchars() but this function covers more character entities. Using this function may also lead to excessive encoding and may cause some content to display incorrectly.
- strip_tags() – This function removes content between HTML tags. This function also does not filter or encode non-paired closing angular braces.
- addslashes() – The addslashes() function adds a slash character in an attempt to prevent the attacker from terminating the variable assignment and adding the executable code at the end.
- Content Security Policy (CSP) – CSP is the last option that we choose to defend against XSS attack. The use of CSP puts restrictions on the attacker’s actions. Our browser executes all the JavsScript it receives from the server, whether they be internally sourced or externally sourced. When it comes to an HTML document, the browser fails to determine whether the resource is malicious or not. CSP is an HTTP header that whitelists a set of trusted resource sources that a browser can use to determine trust in the incoming resource.
X-Content-Security-Policy: script-src 'self'
The above line implies the browser to only trust the source URL which refers to the current domain. All the inputs for resources will be grabbed by the browser from this source only and all the others will be ignored.
There are many resource directives that we can add. Some of them are given below –- connect-src: Limits the sources to which you can connect using XMLHttpRequest, WebSocket, etc.
- font-src: Limits the sources for web fonts. frame-src: Limits the source URLs that can be embedded on a page as frames.
- img-src: Limits the sources for images. media-src: Limits the sources for video and audio.
- object-src: Limits the sources for Flash and other plugins. script-src: Limits the sources for script files.
- style-src: Limits the sources for CSS files.
- Third Party PHP Libraries – There are also some third party PHP libraries that help in prevention of XSS. Some of these are listed below –
- htmLawed
- PHP Anti-XSS
- HTML Purifier
Among all of these, HTMLPurifier is frequently maintained and updated. It is quite simple to use, once the developer has attained a basic level of HTML scripting knowledge.
Conclusion: As a guiding principle, we should try not to insert user-controlled data unless it’s explicitly needed for the application to function. Comments can be its best example where a user can enter malicious XSS causing scripts. This can more often be seen as serving no functional purpose to the application but also introducing some serious security vulnerabilities.
