Alturo Mutual testing
1.Cross Site Scripting (Reflected)
Cross site scripting (also referred as XSS) is a vulnerability that allows an attacker to send
malicious code (usually in the form of JavaScript) to a user. As the user will not know
whether the script can be trusted or not, it will execute the script in the user context allowing
the attacker to access any cookies or session tokens retained by the user.
Remedy:
Validate user inputs with black & whitelist filters and Output encoding must be enforced.
Vulnerable location: Search
SQL Vulnerability:
SQL Injection is one of the many web-based attack mechanisms used by hackers to steal
data from an organization. It is possibly one of the most common application layer attack
techniques used now. It is the type of attack that takes advantage of improper coding of our
web applications that allows hacker to inject SQL commands into say a login form to allow
them to gain access to the data held within our database.
In essence, SQL Injection arises because the fields available for user input permits SQL
statements to pass through and query the database directly.
Remedy:
SQL injection can be prevented if we adopt an input validation technique in which an user
input is authenticated against a set of defined rules for length, type, and syntax and also
against business rules.
A very robust method for mitigating the threat of SQL Injection based vulnerabilities is to use
parameterized queries (prepared statements). Almost all modern languages provide built in
libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with
string concatenation.
Vulnerable location: Login page
Proof of Concept (POC):
Demo.testfire.net:
1. Open the URL in browser https://demo.testfire.net/bank/main.jsp
2. Click login.
3. Enter the ‘Username’ field as 1’or’1’=’1-- and ‘password’ as 1’or’1’=’1—
4. Click on submit button.
Password field submitted using GET method:
This page contains a form with a password field. This form submits user data using the GET
method, therefore the contents of the password field will appear in the URL. Sensitive and
vital information should not be passed via the URL.
Remedy: The password field should be submitted through POST instead of GET.
Insecure Direct Object Reference:
when an application provides direct access to objects based on user-supplied input. As a
result of this vulnerability attackers/hackers can bypass authorization and access resources
in the system directly, for example database records or files.
Remedy:
Update the latest version of phpMyAdmin and restrict the URL to access.
Avoid exposing our private object references to users whenever possible, such as primary
keys or filenames. Validate any private object references extensively with an "accept known
good" approach. Verify authorization to all referenced objects.
Vulnerable location:
Clickjacking:
The application does not prevent itself being loaded in a frame. A malicious site could load
this site in a frame and disguise the UI, tricking users into clicking in certain areas to execute
functions inside the application.
Remedy:
For users of modern browsers, set the X-Frame-Options HTTP response header to "DENY",
"SAMEORIGIN" or "ALLOW-FROM" as appropriate. Ensure that any sites listed under
ALLOW-FROM or SAMEORIGIN also have effective anti-click jacking defenses. Encourage
users to keep browsers up to date. To enable this header at the server level in Apache,
enable mod-headers and add 'Header set X-Frame-Options SAMEORIGIN' to the config file.
In IIS, add the literal header in the "HTTP Headers" tab of IIS Manager.
Vulnerable location: Every Page
HTML CODE:
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<title>i Frame</title>
</head>
<body>
<h3>This is clickjacking vulnerable</h3>
<iframe src="https://demo.testfire.net/bank/main.jsp” frameborder="2 px" height="500px"
width="500px"></iframe>
</body>
</html>
Multiple Session for a user:
The application allows multiple session for every single user.
Remedy:
It is recommended to web application not allow a user to have more than one session active
at a time. Once a new session is active it is recommended to kill the old session for that
user.
Vulnerable location: NA
Account lockout policy not maintained:
Account lockout policy disables a user accounts if an incorrect password is entered a
specified number of times over a specified period. These policy settings help you to prevent
attackers from guessing users' passwords, and they decrease the likelihood of successful
attacks on our network.
Remedy:
It is strongly recommended to maintain an account lockout policy.
Vulnerable location: login page
Session does not timeout
Application does not maintain an appropriate session timeout policy after a certain idle time
of user inactivity. The application allows idle sessions to remain valid for too long. This can
be exploited by an attacker who takes control of a legitimate user's unattended workstation
and allows more time for a remote attacker to try to steal a valid session token.
Remedy:
Destroy the session on the server and force the browser to navigate away from any sensitive
pages after an appropriate interval of idle time.
Vulnerable location: NA
