Web Application Architecture
Most dynamic web applications primarily consist of three components as shown below.
Client Server Database
The following figure shows a simple dynamic web application architecture with Login workflow. Following is a brief description of these three components. Client: Client is usually a web browser or command line client like cURL. There are several technologies used on the client side of a web application and they are usually intended to be executed in the browsers. Examples of client side technologies are HTML, CSS, JavaScript and Flash. Server: Server component processes the requests received from the client. Server component can be a web server or an app server. If it is a web server, it serves web pages in response to the client requests. In some cases, application servers might be involved in this chain to process the client requests. In such cases, the web server will just forward the requests to the application server. Just like the client side, there are several technologies used on the server side too. Apache, Nginx, IIS are some examples of popular web servers. Apache Tomcat, Oracle WebLogic, Jboss are some examples of app servers. When it comes to programming languages used to write server side programs, PHP, ASP, C#, Java and Python are some examples. Database: Database is considered as the storage backend, which is used to save and retrieve data. MySQL, Oracle, MSSQL and PostgreSQL are some examples of commonly used relational databases. NoSQL databases such as MongoDB or CouchDB may also be used. The use of JavaScript on the client side: Client side technologies like HTML merely offer static content and any processing on the browser’s side requires the execution of JavaScript. JavaScript has proven to be a widely used language in the client side due to the richer, desktop like user experience it provides. Let us consider the following innocent looking code snippet located within a HTML page on the client site. { var myurl = document.URL; if(myurl.indexOf(“?search=”)>0) { document.getElementById(‘srch’).innerHTML = “You’ve searched for “+unescape(myurl.substr(myurl.indexOf(“?search=”)+8)); } } This code snippet takes a value from the URL query parameter search and inserts it into the HTML DOM (Document Object Model). The code snippet is used to show the user the keyword he/she has searched for. In this case, the user can control the URL query parameter search and can possibly inject custom JavaScript forcing the application to execute user supplied code. This ability of a user being able to execute arbitrary JavaScript code in the context of a target application is commonly known as Cross Site Scripting and it can lead to a variety of attacks such as session hijacking using cookie stealing, keystroke logging and phishing. When web applications receive user input from the users and insert it into the client side code without properly validating it, it causes Cross Site Scripting vulnerabilities. Let us consider the following feature of a shopping cart application, where a user can search for products. Notice how the application receives user input and displays it back on the webpage. The search item jackfruit is entered by the user and it is echoed back as is. In such scenarios, if a user enters JavaScript instead of text, it gets executed by the application when the developers do not implement sufficient input validation or output encoding. This looks as follows. As we can notice in the preceding figure, the user entered JavaScript is executed by the application. This confirms that the application is receiving user entered data and treating it as code. Cross Site Scripting vulnerabilities are broadly categorized into 3 types as shown below.
Reflected Cross Site Scripting Stored Cross Site Scripting DOM based Cross Site Scripting
Reflected Cross Site Scripting: Reflected XSS occurs when user supplied JavaScript is injected into the client without sufficient input validation or output encoding. Stored Cross Site Scripting: Stored XSS occurs when user supplied JavaScript is stored with a datastore like a database and later injected into the client due to lack of input validation or output encoding. DOM based Cross Site Scripting: DOM XSS occurs when user supplied JavaScript is injected into the browser’s DOM without sufficient input validation or output encoding.
Conclusion:
In this article, we have discussed web application architecture and an introduction to XSS vulnerabilities. Client Side Injection vulnerabilities can be very dangerous and they cannot be underestimated. They add great risks to the applications as well as users. In the next few articles, we will discuss more cross site scripting related concepts such as their causes, exploitation techniques and mitigations.
Sources:
https://owasp.org/www-community/attacks/xss/ https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.html https://owasp.org/www-project-top-ten/
