Web application security.
SQL injection:
The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Beware of APIs, such as stored procedures, that appear parameterized, but may still allow injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.
Positive or "whitelist" input validation with appropriate canonicalization also helps protect against injection, but is not a complete defense as many applications require special characters in their input.
Cross site scripting xss:
The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about data escaping techniques.
Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications must accept special characters. Such validation should decode any encoded input, and then validate the length, characters, and format on that data before accepting the input.
Using xss people can redirect users from your site to another, or get the session ids of your users and do session fixation etc.
Cross site forgery:
The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
Failure to restrict private url access & Insecure direct object references:
Just by chaning the parameters passed in the forms / urls users should not get access to what they are not supposed to access.
or just by pasting the internal urls users should not be able to view the internal pages with out login.
Broken session management:
- You dont logout the user after some time of inactivity: If user forgets to logout, some one else can auto login.
- If you use session ids in the url, if another user gets access to that url in the meantime, he can use the session.
- Regenerate the session id on every request to avoid session fixation.
http://shiflett.org/articles/session-fixation
instead of
session_start();
if (!isset($_SESSION['count']))
{
$_SESSION['count'] = 0;
}
else
{
$_SESSION['count']++;
}
echo $_SESSION['count'];
?>
use
session_start();
if (!isset($_SESSION['initiated']))
{
session_regenerate_id();
$_SESSION['initiated'] = true;
}
?>
Password should be encrypted and stored:
Security misconfiguration:
directory listing.
older version of frameworks
exposing server version numbers.
The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Beware of APIs, such as stored procedures, that appear parameterized, but may still allow injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.
Positive or "whitelist" input validation with appropriate canonicalization also helps protect against injection, but is not a complete defense as many applications require special characters in their input.
Cross site scripting xss:
The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about data escaping techniques.
Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications must accept special characters. Such validation should decode any encoded input, and then validate the length, characters, and format on that data before accepting the input.
Using xss people can redirect users from your site to another, or get the session ids of your users and do session fixation etc.
Cross site forgery:
The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
- using posts and referrer header checks helps to an extent.
Failure to restrict private url access & Insecure direct object references:
Just by chaning the parameters passed in the forms / urls users should not get access to what they are not supposed to access.
or just by pasting the internal urls users should not be able to view the internal pages with out login.
Broken session management:
- You dont logout the user after some time of inactivity: If user forgets to logout, some one else can auto login.
- If you use session ids in the url, if another user gets access to that url in the meantime, he can use the session.
- Regenerate the session id on every request to avoid session fixation.
http://shiflett.org/articles/session-fixation
instead of
session_start();
if (!isset($_SESSION['count']))
{
$_SESSION['count'] = 0;
}
else
{
$_SESSION['count']++;
}
echo $_SESSION['count'];
?>
use
session_start();
if (!isset($_SESSION['initiated']))
{
session_regenerate_id();
$_SESSION['initiated'] = true;
}
?>
Password should be encrypted and stored:
Security misconfiguration:
directory listing.
older version of frameworks
exposing server version numbers.
