1. Executive Summary
Our team conducted a penetration test on Deepika Online GMPH to identify vulnerabilities that could allow unauthorized access to sensitive systems and data. The goal was to simulate real-world attacks and measure the resilience of the applications.
One with the goals of:
- Identifying if a remote attacker could penetrate {MASKED} defenses.
- Determining the impact of a security breach.
Efforts were placed on the identification and exploitation of security weaknesses that could allow a remote attacker to gain unauthorized access to organizational data. The attacks were conducted with the level of access that a general Internet user would have. Overall, It was able to achieve the goals of the assessment and exfiltrate the targeted data.
The key strong points of application are
- Browser validation on login
- Strong input validation
- Logout on security checks
The Key weaknesses are
- Input validation is not enforced in few areas.
- Access controls are not enforced in few areas.
Overall, STC was able to achieve the goals of the assessment and exfiltrate the targeted data. There were
a number of critical findings during the assessment including the following:
- Total number of findings: 14
- Total number of critical findings: 8
- Total number of high findings: 1
- Total number of moderate findings: 4
- Total number of low findings: 1
- Total number of informational findings: 0
2 . Findings
Critical Risk Findings
SQL Injection on CLP/admin/view_cardlist.php
SQL Injection on CLP/admin/showtest.php
SQL Injection on CLP/admin/denomination.php
Summary:
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into
data-plane input in order to effect the execution of predefined SQL commands.
Severity: Critical
Remediation:
The following is recommended to prevent SQL Injection:
- Use of Prepared Statements (Parameterized Queries)
- Use of Stored Procedures
- Never trust user input, Escaping all User Supplied Input
Cross-Site Request Forgery
In the majority of today’s web applications, clients are required to submit forms which can perform sensitive operations. An example of such a form being used would be when an administrator wishes to create a new user for the application. In the simplest version of the form, the administrator would fill-in:* Name * Password * Role (level of access)Continuing with this example, Cross Site Request Forgery (CSRF) would occur when the administrator is tricked into clicking on a link, which if logged into the application, would automatically submit the form without any further interaction. Cyber-criminals will look for sites where sensitive functions are performed in this manner and then craft malicious requests that will be used against clients via a social engineering attack. There are 3 things that are required for a CSRF attack to occur:
1. The form must perform some sort of sensitive action.
2. The victim (the administrator the example above) must have an active session.
3. Most importantly, all parameter values must be **known** or **guessable**.The tool discovered that all parameters within the form were known or predictable and therefore the form could be vulnerable to CSRF. Manual verification may be required to check whether the submission will then perform a sensitive action, such as reset a password, modify user profiles, post content on a forum, etc.
Severity: Critical
Remediation:
Based on the risk (determined by manual verification) of whether the form submission performs a sensitive action, the addition of anti-CSRF tokens may be required. These tokens can be configured in such a way that each session generates a new anti-CSRF token or such that each individual request requires a new token. It is important that the server track and maintain the status of each token (in order to reject requests
accompanied by invalid ones) and therefore prevent cyber-criminals from knowing, guessing or reusing them. For examples of framework specific Remediation: options, please refer to the references mentioned below.
High Risk Findings
Privilege escalation to get Credit Due
Applications frequently use the actual name or key of an object when generating web pages. Applications do not always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified. A user could see Credit due information. Which is not accessible to the normal user.
Severity: High Risk
Remediation:
Use per user or session indirect object References:. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. Check access. Each use of a direct object reference from an untrusted source must include an access
control check to ensure the user is authorized for the requested object.
Moderate Risk Findings
Cross Site Scripting (XSS) on report_cashcreditSummary:.php
Cross Site Scripting (XSS) on index.php
Cross Site Scripting (XSS) on add_marquee action
Summary:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script
came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the and used with that site. These scripts can even rewrite the content of the HTML page.
Severity: Moderate
Remediation:
The following is recommended to remediate XSS vulnerabilities:
– Never trust user input
– Never insert untrusted data except in allowed locations
– HTML escape before inserting untrusted data into HTML element content
– Use whitelists in place for Black lists for input filtering
Unrestricted file access on invoice files
Web applications are often made up of multiple files and directories. It is possible that over time some files may become unreferenced (unused) by the web application and forgotten about by the administrator/developer. Because web applications are built using common frameworks, they contain common files that can be discovered (independent of the server). During the initial recon stages of an attack, cyber-criminals will attempt to locate unreferenced files in the hope that the file will assist in further compromise of the web application. To achieve this they will make thousands of requests using word lists containing common filenames. The response headers from the server
will then indicate if the file exists.
Severity: Moderate
Remediation:
Preventing access without authentication may also be an option and can stop a client from being able to view the contents of a file, however it is still likely that the directory structure will be able to be discovered. Using obscure file names is implementing security through obscurity and is not a recommended option.
Low Risk Findings
Session fixation
HTTP by itself is a stateless protocol; therefore, the server is unable to determine which requests are performed by which client and which clients are authenticated or unauthenticated. The use of HTTP cookies within the headers allows a web server to identify each individual client and can thus determine which clients hold valid authentication from those that do not. These are known as session cookies or session tokens.
To prevent clients from being able to guess each other’s session token, each assigned session token should be entirely random and be different whenever a session is established with the server. Session fixation occurs when the client is able to specify their own session token value and the value of the session cookie is not changed by the server after successful authentication. Occasionally, the session token
will also remain unchanged for the user independently of how many times they have authenticated. Cybercriminals will abuse this functionality by sending crafted URL links with a predetermined session token within the link. The cyber-criminal will then wait for the victim to login and become authenticated. If successful, the cyber-criminal will know a valid session ID and therefore have access to the victim’s session.
Severity: Low
Remediation:
The most important Remediation: action is to prevent the server from accepting client supplied data as session tokens. Additionally, the client’s session token should be changed at specific key stages of the application flow, such as during authentication. This will ensure that even if clients are able to set their own cookie, it will not persist into an authenticated session.
