Definition Cross-site scripting also known as XSS is a web security vulnerability thatallows an attacker to compromise the interactions that users have with avulnerable application.. It
Target
- Understanding of threats and security vulnerabilities in information technology systems
- Find out how to take advantage of security flaws Next, determine how to defend systems against those dangers.
Report layout
After the Introduction, the report is presented in three chapters, specifically as follows:
In this chapter, the report presents the concepts and characteristics of the components used to implement the project.
The content presents the results of the process of implementing and developing the topic.
- Chapter 3 Conclusions and development orientations
The content presents achievements and limits and directions for development.
Finally, there are references and appendices related to the topic
RESEARCH OVERVIEW
Cross-site scripting (XSS)
Cross-site scripting (XSS) is a significant web security vulnerability that enables attackers to exploit user interactions with affected applications By bypassing the same origin policy, which separates different websites, attackers can impersonate legitimate users, execute actions on their behalf, and access sensitive user data If the compromised user has elevated privileges, the attacker may gain complete control over the application's features and data.
Cross-site scripting (XSS) exploits vulnerabilities in websites to deliver harmful JavaScript to users Once executed in a victim's browser, this malicious code allows attackers to completely compromise the user's interaction with the affected application.
There are three main types of XSS attacks These are:
- Reflected XSS, where the malicious script comes from the current HTTP request.
- Stored XSS, where the malicious script comes from the website's database.
- DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
Reflected XSS is the most basic form of cross-site scripting, occurring when an application takes data from an HTTP request and incorporates it into its immediate response without proper security measures.
Here is a simple example of a reflected XSS vulnerability:
The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:
Stored XSS, or persistent XSS, occurs when an application accepts data from an untrusted source and subsequently includes that data in its HTTP responses without proper security measures.
Data can be submitted to applications through HTTP requests, such as blog comments, chat room nicknames, or customer contact details Additionally, data may originate from untrusted sources, including webmail applications that show SMTP messages, marketing apps displaying social media content, or network monitoring tools revealing packet data A common example of a stored XSS vulnerability occurs in a message board application where users can submit messages that are subsequently displayed to others.
The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:
1.3.3 DOM-based cross-site scripting
DOM-based XSS, or DOM XSS, occurs when an application uses client-side JavaScript to handle data from an untrusted source insecurely, typically by injecting this data back into the DOM.
In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:
If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:
In a typical scenario, an attacker can exploit an input field by manipulating a URL query string parameter from an HTTP request, enabling them to execute an attack similar to reflected XSS through a malicious URL.
1.4 What can XSS be used for
An attacker who exploits a cross-site scripting vulnerability is typically able to:
- Impersonate or masquerade as the victim user.
- Carry out any action that the user is able to perform.
- Read any data that the user is able to access.
- Capture the user's login credentials.
- Perform virtual defacement of the web site.
- Inject trojan functionality into the web site.
The actual impact of an XSS attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For example:
- In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
- In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
If a compromised user holds elevated privileges within the application, the consequences can be severe, enabling the attacker to gain complete control over the vulnerable application and jeopardize all users and their data.
1.6 Finding and testing for XSS
The vast majority of XSS vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.
To manually test for reflected and stored XSS vulnerabilities, submit unique inputs, like short alphanumeric strings, at every entry point of the application Identify all locations where the input appears in HTTP responses and test each one individually to see if crafted input can execute arbitrary JavaScript This approach helps determine the context of the XSS and select an appropriate payload for exploitation.
Manually testing for DOM-based XSS from URL parameters involves inputting unique data into the parameter and using browser developer tools to check the DOM for vulnerabilities However, detecting other types of DOM XSS, especially from non-URL inputs like document.cookie or non-HTML sinks such as setTimeout, requires thorough JavaScript code review, which can be very time-consuming To streamline this process, Burp Suite's web vulnerability scanner utilizes both static and dynamic analysis of JavaScript to effectively automate the detection of DOM-based vulnerabilities.
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user- controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
- Filter input on arrival At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
To enhance security, it is crucial to encode user-controllable data in HTTP responses This encoding prevents the data from being misinterpreted as active content Depending on the specific context of the output, it may be necessary to utilize a combination of HTML, URL, JavaScript, and CSS encoding techniques.
To mitigate XSS risks in HTTP responses not meant for HTML or JavaScript, it is essential to utilize the Content-Type and X-Content-Type-Options headers These headers help ensure that browsers interpret the responses correctly, aligning with your intended content type.
- Content Security Policy As a last line of defense, you can use ContentSecurity Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
Server-side request Forgery (SSRF)
Server-Side Request Forgery, or SSRF, is a security vulnerability that allows malicious actors to manipulate the server into making unintended requests on behalf of the server itself.
In applications susceptible to Server-Side Request Forgery (SSRF), attackers take advantage of the server's capability to send HTTP requests to restricted resources that are not meant to be publicly accessible These resources can include internal APIs, protected websites, or databases that are only reachable from the server itself.
Attackers achieve this by tricking the server into making unintended requests to various destinations, including internal APIs, internal HTML pages, and internal databases.
SSRF works by exploiting a vulnerability in a web application that allows an attacker to manipulate the server to send unauthorized requests to other internal or external systems.
An attacker exploits a vulnerable server by sending a specially crafted URL that deceives the web application into believing the request comes from a trusted source The server, failing to adequately validate the target URL, unwittingly trusts its own requests, creating a security risk.
An attacker can exploit a manipulated request to target various internal or external systems, such as databases and network resources, as well as third-party services This manipulation enables the extraction of sensitive data and the execution of other malicious activities.
An attacker can exploit a manipulated request to target various internal or external systems, such as databases and network resources, as well as third-party services This enables the attacker to extract sensitive data or execute other malicious activities.
A server-side request forgery (SSRF) attack occurs when attackers manipulate a process that allows a browser or client system to access a URL on the server directly By substituting the original URL with one that points to the local file system—often using the IP address 127.0.0.1 or the hostname "localhost"—attackers can uncover sensitive data stored on the server.
A weather website utilizes a web application to retrieve current weather forecasts by querying its server through a REST API This process involves sending an API request from the user's browser to the server via a specific URL.
The server may inadvertently reveal the contents of the /admin folder to an attacker, as the request operates within the server's file system This process circumvents standard access controls, allowing unauthorized individuals to access sensitive information.
A variant of Server-Side Request Forgery (SSRF) occurs when a server maintains a trusted relationship with a back-end component If the server possesses full access rights during its connection to this component, an attacker may exploit this vulnerability by forging requests, potentially gaining access to sensitive data or executing unauthorized operations This risk is heightened as back-end components frequently have weaker security measures, being perceived as secure within the network perimeter.
Continuing the previous example, the attacker could replace the API call with:
If a server connects to a back-end component at the IP address 192.168.12.5 and has permission to access the /admin directory, an attacker can exploit this vulnerability to gain unauthorized access and view the directory's contents.
SQL Injection
SQL injection is a critical web security vulnerability that enables attackers to manipulate SQL queries made by an application to its database, potentially granting unauthorized access to sensitive data, including information from other users This exploitation can lead to data modification or deletion, resulting in lasting alterations to the application's content and functionality.
A successful SQL injection attack can result in unauthorized access to sensitive data, such as: passwords, credit card details, personal user information,
SQL injection is a common security vulnerability where an attacker inserts malicious SQL code into a web application's database query This often occurs through user input in forms, which, if not properly sanitized, allows the attacker to manipulate the back-end database Consequently, they can delete, copy, or modify the database contents, posing significant risks to data integrity and security.
In this scenario, an attacker manipulates an input field by entering a SQL command, specifically a student ID of “171 or 1=1;-” This alters the database query from searching for a specific ID to evaluating whether 1 equals 1, which is always true Consequently, the database returns all records from the students table to the attacker, exposing sensitive information.
3.3 SQL Injection prevention and mitigation
There are number of methods for reducing the risk of a data breach due to SQL injection:
Using prepared statements with parameterized queries is an effective method for sanitizing database inputs This approach requires developers to define all SQL code upfront and only pass specific parameters to the query, ensuring that the data entered is limited in scope By doing so, the database can differentiate between user input and executable code, regardless of the data type provided Additionally, many object-relational mapping (ORM) libraries facilitate this process, as certain versions automatically sanitize database inputs.
- Escape All User Supplied Input: When writing SQL, specific characters or words have particular meaning For example, the ‘*’ character means
To prevent issues caused by users inadvertently or intentionally entering the characters "any" and "OR" in API requests, it is essential to escape user-supplied input Escaping characters instructs the database to interpret them as literal input rather than as commands or conditionals, enhancing security and ensuring accurate data handling.
Stored procedures can enhance security by mitigating SQL injection risks, although they should not be relied upon as a standalone solution By restricting the permissions of the database account executing SQL queries, even vulnerable application code is limited in its ability to access unrelated tables Additionally, stored procedures can validate input parameter types, ensuring that only appropriate data is accepted However, they are generally not recommended when static queries are inadequate.
To mitigate the risk of SQL injection, it is essential to enforce the principle of least privilege by restricting permissions to the minimum necessary for executing dynamic SQL queries This means that administrative accounts should never execute SQL commands from unauthorized API requests While stored procedures are ideal for static queries, applying least privilege principles can significantly enhance security for dynamic SQL operations.
Insecure Design
Insecure design vulnerabilities arise from neglecting security best practices in the design phase, making them a primary contributor to functionality failures, data breaches, policy violations, and damaged reputations.
It is a broad category that encompasses a wide range of weaknesses, such as:
- Lack of Input Validation: The application does not properly validate user input,which can allow an attacker to inject malicious code into the application
- Improper Session Management: The application does not properly manage user sessions, allowing an attacker to hijack a session and take control of the victim's account
- Insecure Data Storage - This means that the application does not properly store sensitive data, allowing an attacker to access and steal the data
- Insecure Communication - The application does not properly secure communication between the client and the server, allowing an attacker to intercept and modify data
Attackers can exploit vulnerabilities arising from the failure to implement secure design principles, leading to issues such as inadequate access control, authentication bypass, cross-site scripting, and various injection vulnerabilities The following scenarios illustrate how these security weaknesses can infiltrate the development process and be targeted by malicious actors.
The application utilizes a unique identifier in the URL for easy access to user information, simplifying management and development However, this design poses a security risk, as attackers can manipulate the URL by incrementing IDs to access valid user data The risk escalates if the unique identifiers are sequential rather than random, making it easier for malicious users to enumerate URLs.
An example of a security vulnerability occurs when a legitimate user is logged into the website https://flts.huflis.edu.vn/account/studentinfo/21f7511111 An attacker can exploit this by altering the URL to https://flts.huflis.edu.vn/account/studentinfo/21f7511112, potentially gaining access to another user's information.
4.3 Insecure Design prevention and mitigation
Apply the STRIDE model for identifying threats at each access point. Developed at Microsoft, STRIDE is a mnemonic for six categories of security risk:
- Information disclosure (privacy breach or data leak)
Applications managing sensitive data should implement a data classification strategy to categorize information effectively This approach allows organizations to focus on safeguarding the most critical data For example, data items can be classified into various categories based on their sensitivity levels.
- Public data - data available to everyone, like company blogs
- Private data - data available to authenticated users
- Restricted data - sensitive data that may be owned by particular users, like profile information
- High risk data - access tokens, passwords and credentials for third-party APIs that must never be shared
This will help you pick out high-value information likely to be targeted by attackers
After modeling your threats, the next step is to translate that information into specific security requirements To effectively meet these requirements, it is essential to adopt a structured Software Development Life-Cycle (SDLC), ensuring that the code developed addresses the right issues.
A good SDLC consists of the following elements:
Effective source control is essential for any development team, as it ensures that all code is securely stored in a version control system like Git before deployment This practice not only facilitates the analysis of code changes for potential security vulnerabilities but also enables thorough reviews of the code operating in the production environment.
Automating your build process is essential to eliminate inconsistencies between the code tested and the code deployed in production This typically involves utilizing a package manager for dependency management and creating a build script to compile the code or generate necessary assets.
Incorporating unit testing into your build process is essential for ensuring that security requirements are met, such as restricting profile page access to authenticated users Additionally, unit tests serve as valuable documentation, helping to track changes in the code over time.
Continuous Integration is essential for maintaining code quality, as it ensures that the build process and unit tests are executed each time code is pushed to source control This practice provides the development team with immediate feedback, allowing them to quickly identify and address any security requirement violations introduced by recent code changes.
Code reviews are essential for maintaining software security and quality, as every code change should be evaluated by a reviewer who is not the original author before deployment This practice ensures that potential security flaws are identified and addressed, providing an additional layer of scrutiny and enhancing the overall integrity of the code.
Simplifying the deployment process for testing and production environments is crucial Implementing a push-button deployment system minimizes the risk of human error, ensuring that your code is deployed smoothly and efficiently without complications.
Implementing rollback capability is crucial for maintaining software integrity Establishing a clear process for reverting releases allows for the swift deployment of previous code versions This becomes particularly vital when a security vulnerability is identified, enabling teams to promptly rectify mistakes and safeguard the system.
Secure design is fundamentally a philosophical approach that emphasizes the importance of applying key principles when writing code to mitigate unforeseen security risks By adhering to these essential touchstones, developers can significantly enhance the security posture of their applications.
The principle of least privilege dictates that every user, program, and process should function with only the minimum privileges necessary to fulfill their objectives Implementing this principle effectively reduces the potential damage an attacker can inflict upon your system in the event of a successful compromise.
- Validation of input Validate any input coming from an untrusted source (like an HTTP request) to ensure it is the expected format, and reject it otherwise.
- Segregation of tenants Different environments (production and test) should be on separate networks and not share resources or configuration.
- Encryption Encrypting data at rest and in transit will protect against monster-in-the-middle attacks and prevent sensitive information from being read if it is stolen.
End of chapter 1
Understanding the knowledge in the theoretical thesis chapter is the basis for the next phase of the project - implementation, which will be presented in the next chapter.
IMPLEMENTATION
Experiment with XSS attack techniques
Target URL: https://thethao365.com.vn/
According to SimilarWeb statistics, the website has about 35 thousand visits per month
Build a server to receive cookies from the victim We use node js and express js for this.
1.3 Create links containing malicious code
Below is the code that takes advantage of the XSS error to retrieve the victim's cookie and send it to the server built above
An XSS error was detected in the website's search box
After entering the malicious code into the search box and pressing Enter, we receive the following url
Once the victim accesses the malicious link above, the victim's cookie is sent to the server, below is the result.
By obtaining the cookie, we can gain unauthorized access to the victim's account without needing their password, allowing us to carry out actions on the website as if we were the victim.
Figure 1 14 Access victim’s account successfully
Server-side request Forgery(SSRF)
Website has Server-side request forgery (SSRF): https://0ae1009a0460d47d832c66e600410020.web-security-academy.net/
2.2 Visit a product, click "Check stock", intercept the request in BurpSuite, and send it to Burp Intruder.
2.3 Brute force all capabilities of this IP to find the correct URL.
- Send request to Intruder function.
- Place the payload marker at the location that needs to be brute-forced.
- Observe that IP 192.168.0.201 returns status code 404 and in the response contains the admin page function:
2.4 Access the existing URL and delete the carlos user account.
- Linux machine: Kali Linux, Ubuntu or WSL,…
- Install sqlmap on linux machine: sudo apt-get install sqlmap
- Website has SQL Injection vulnerability: https://www.mayinchuyennhiet.vn/
Figure 1 22 SQL Injection target website
3.2 Exploit the database of website
- Get the cookie of website: open Dev Tools (F12) → Application → Cookies → https://www.mayinchuyennhiet.vn
- Run command to get the databases of website: sqlmap -u “https://www.mayinchuyennhiet.vn/?php=product_detail&id06” cookie="PHPSESSID=uvkhm38bt5pl7asj39p0lfg4o0" risk=3 thread dbs
→ There are 2 databases of website:
To enumerate all tables in the database "mayinchuye_binh," execute the following command: `sqlmap -u "https://www.mayinchuyennhiet.vn/?php=product_detail&id06" cookie="PHPSESSID=uvkhm38bt5pl7asj39p0lfg4o0" risk=3 threads -D mayinchuye_binh tables`.
→ We got 10 tables in the database:
Delivery is available with payment upon receipt Orders will be processed within 2 to 4 hours after placement Our skilled technicians possess extensive experience and provide attentive after-sales service Enjoy a 14-day free return policy We are a reputable brand.**Company Information**This website is owned by Long Cường Phát Trading Company Limited Our address is 196/9 Tân Sơn Nhì, Tân Phú District, Ho Chi Minh City Tax code: 0312022143 Contact us at (028) 6683 8068 or via email at mucincuongphat@gmail.com Our legal representative is Huỳnh Văn Cường, and we hold a business license issued on 07/08/2019 by the Department of Planning and Investment of Ho Chi Minh City Our operating hours are from 8:00 AM to 5:30 PM For inquiries, please call 0935.57.67.78, 0935.26.77.78, or 098 9999 987.
The table "tble_user" includes columns for id, uid, cat_id, and an MD5-encrypted password To attempt decryption of the password, sqlmap can be utilized For the user identifier "coder," the password is "123456789s."
SQL Injection is a critical security vulnerability that allows attackers to manipulate a website's database, potentially leading to unauthorized access to sensitive data This exploitation can enable malicious actors to alter product prices and generate fraudulent orders using users' delivery information.
Exploit a vulnerability that exists on a website with the url: https://flts.huflis.edu.vn
Figure 1 27 Insecure design target website
According to SimilarWeb statistics, the website has about 117 thousand visits per month
4.2.1 Logging In and Viewing Network Requests
To begin, log in and access the personal information page Open Dev Tools by pressing F12 and navigate to the Network tab to observe the requests being made Here, you will find a request that retrieves the user's information.
The program poses a security vulnerability by permitting unauthorized access to personal information through data (ID) supplied in the URL To enhance security, it is essential for the program to verify whether users have the appropriate permissions to access this sensitive data.
Run the code below to get a list of user information The result is a list of user information.
The result is a list of user information.
CONCLUSIONS AND DEVELOPMENT ORIENTATIONS .30 1 Conclusions
Development
Additional information is needed on specific techniques to carry out attacks using XSS, SSRF and SQL Injection vulnerabilities.
Need to provide tools and software to support finding and exploiting vulnerabilities.
It is necessary to update the latest security measures to prevent these vulnerabilities.
Research into more advanced prevention methods is needed, such as using artificial intelligence to automatically detect and prevent attacks.