OWASP 10

OWASP 10(Open Web Application Security Project)

SQL INJECTIONS

·        What are SQL Injections?

1.     When untrusted data is taken from user input and applied to some kind of query or interpreter in a way that assumes what the data will look like.

2.     An attacker enters data that does not fit the expected input but malforms it in some way to have unintended consequences, such as error leakage, damage to data or exposure of data.

3.     An attacker can bypass any client-side controls that might be intended to stop this.

4.     Usually related to SQL but can also apply to LDAP or operating system calls or anything that builds a query from user input.

5.     It is not the most common but it is the most serious vulnerability found   in web applications.

6.     If the site is susceptible, it is usually quite easy to take advantage of.

7.     It is usually easy to find out if a site is susceptible.

8.     Many frameworks are vulnerable by default or easily allow the   vulnerability.

·        Prevention measures:

1.     All the web application must use filters for all user input, the user input should be filtered as per the context of input. For an example the phone numbers should allow digits, plus sign for code and so on.

2.     Use of ModSecurity, it is open source web application firewall which is available for Apache, Microsoft IIS and nginx web servers. It is use to filter dangerous web requests.

3.     Fixing an existing site might be harder due to the size or complexity of code.

4.     Parameterized queries allow the framework to escape user input.

5.     Stored procedures allow you to restrict what the application can action on the database e.g. not permit select * from users.

6.     Input validation should be applied, server-side to ALL user input in as restrictive a way as possible.

7.     Do not rely on input validation alone if possible.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT

·        What is Broken authentication and session management ?

1.     If an authentication or session management systems not correctly implemented, an attacker can impersonate someone else and gain access to data or functionality that they shouldn't.  

2.     Authentication and session often involve cookies which provide a very easy way for an attacker to try and impersonate someone else.

3.     The authentication system itself might be bypassed or permissions elevated if the developer has not coded it correctly.

4.     This is very common on older applications and on those that have been most written from scratch.

5.     Modern featured frameworks are usually secure by design but where someone has extended built-in functionality, or replaced it there is always a danger of breaking security.

·        Prevention measures:

1.     The ideal is to use a modern framework where the mechanism has seen a lot of public use and testing.

2.     If you cannot rewrite your application, it might be possible to copy in the code from a modern framework that handles authentication and session management.

3.     Be particularly mindful of your password hashing algorithm, as passwords are often a target for attackers.

4.     Use https only and ideally secure flags on cookies.

5.     Use a combination of pen-testing and code review to test the session handling code.

XSS (Cross Site Scripting )

·        What is XSS (Cross Site Scripting)?

1.     Running some active content, usually a script, within someone else's page.

2.     The victim trusts the real page and therefore trusts the attacker’s payload.

3.     Attacker can send a link to a victim which is a real link to a real site but which has been compromised.

4.     OWASP say that XSS is the most prevalent Web application security flaw.

5.     Because it is there from the days that security wasn't taken seriously.

6.     The vulnerable web application is used as an attacker but might also be the target.

·        Prevention Measures

1.     Very easy: validation and encoding.

2.     Content Security Policy (CSP) is also fairly easy and helpful.

Insecure direct object references

·        What are Insecure direct object references?

1.     When a URL contains some reference to an object, e.g. index id=12345, then if permissions are not setup correctly, someone can change this value and potentially access data they should not.

2.     Missing out access control in general is common and this particular vulnerability is also common because very few frameworks are able to enforce this sort of behavior automatically.

3.     Exploitability is VERY easy but it is also easy to identity and test whether your application is vulnerable.

 

·        Prevention measures:

1.     Everywhere that an object reference is used, permission must be checked for the current user before returning the item to the user.

2.     Disallowed access should be logged and monitored as a potential attack.

3.     You can use randomized/anonymized access ids but this is somewhat complex and not necessarily more effective than simply verifying access.

Security Misconfiguration

·        What is Security Misconfiguration?

1.     A general note that configurations for applications, servers, firewalls, databases etc. use best-practice and that all settings are considered and checked.

2.     Default pages or accounts

3.     Unused pages or services

4.     Error data leakage

5.     Unpatched/non-updated systems

6.     Unprotected files and directories

7.     Most web servers and frameworks do not have a completely secure configuration by default.

8.     Debugging settings should be removed in production code if they produce a vulnerability but this isn't always done.

9.     Configurations can be very complex and it isn't always obvious where a vulnerability might be introduced

·        Prevention measures:

1.     Configuration requires learning about multiple technologies

2.     There are plenty of books about secure web server setup.

3.     Use code-review and deployment checklists to ensure that things aren't missed — this is the most basic repeatable/self-improving quality control.

4.     Automate things where possible e.g. configuration transforms.

5.     Pay attention to security announcements on the web.

6.     Have an update plan to ensure that patches etc. are applied at suitable times*.

Sensitive data exposure

·        What is sensitive data exposure?

1.     Some data has high value e.g. credit cards, email addresses, other personal data.

2.     If this data is not correctly handled by your application, data exposure is a serious risk and therefore a more likely a bad outcome.  

3.     Evidence suggests that very few applications have a pessimistic encryption policy on data most people store things in plain text.

4.     Encryption might be applied at the wrong level e.g. the database hard disk is encrypted but the data itself is vulnerable to direct injection attacks.

5.     Various sites are found out not even to apply PCI DSS requirements for credit cards or age (i.e. not storing numbers after use and storing the CVV number

6.     Insecure storage and the ability to attack it are not the same however. Attacking weak crypto in itself is usually hard.

7.     Very severe potential outcome.

·        Prevention measures

1.     Take a considered view as to the value of your data

2.     Learn about encryption.

3.     Encryption is generally lightweight on modern hardware, so choose to apply it rather than not.

4.     Look at encryption at different application levels and consider risks associated with different types of attack vector.

5.     Do not store encryption keys in the same place as the data it is encrypting.

6.     Use hardware protection for encryption keys wherever possible.

Missing Function level access control 

       What is Missing function level access control?

1.   It is common that authorization checks are used to generate appropriate menus and even possibly to show and hide various options within a page e.g. an edit link for an administrator, however, these same checks are not usually made on the function itself.

2.   If an attacker is aware of the presence of these other functions, they can attempt to call them, even though they are hidden, the functions are likely to do what they are designed for if they perform no checks.

3.   The target is generally privileged or Administrator functions since this vulnerability is attempting to create an "Escalation of privilege"

         4.    Lack of function-level access control is very common.

         5.     It is another control that is hard for a framework to enforce    automatically — i.e. it requires the developers to know about it.

·        Prevention measures

1.     Each piece of functionality that is not permitted by all users’ needs a function-level access check.

2.     It is acceptable to apply)t even if the permission is allowed for everyone.

3.     Use a code-review checklist to ensure this has been considered and implemented.

Cross site request forgery (CSRF)

·        What is Cross site request forgery(CSRF) ?

1.     An attacker abuses the trust that the browser has with a target site by asking the site to carry out an action on behalf of the user.

2.     This action will take advantage of any current session that the victim might have open by automatically sending session cookies to the target site.

3.     This works because browser tabs share session.

4.     It is very easy to attack if the site does not have a mechanism to ensure that the action has been invoked from its own pages.

5.     On older sites, it is very common

6.     Most modern frameworks have built-in CSRF protection but it is not always enabled by default!

7.     Some sites only have per-session CSRF protection which allows a much harder type of attack to still take place

8.     Sites that have per-page CSRF protection are more secure but can cause usability problems if the same site is opened in multiple tabs.

 

·        Prevention measures

1.     Find out how your framework supports CSRF protection, it might be very easy to enable it without doing any additional work

2.     Find out whether your framework uses per-session or per-page CSRF protection and consider their trade-offs.

3.     Test that your site actually implements it correctly by trying to replay a POST from a form and seeing whether the action is permitted. Note that an attacker will only have code from their own visit to the site and not the contents of the targets visit.

4.     NEVER use GET for changing data in your application!

Components with known vulnerabilities

·        What are component with known vulnerabilities?

1.     Many of us use third-party components to provide functionality to our web sites. It is not always easy to know whether these contain vulnerabilities, either generally or in a particular configuration.

2.     These third-party components can add vulnerabilities that are anywhere from subtle to serious.

3.     These components exist at different levels in our application stack such as application, database, operating system or web server.

4.     Most applications probably have a number of vulnerabilities although many will be impossible to attack due to other controls or the specific configuration.

5.     Most of the major vulnerabilities are well-known and become news stories.

6.     Vulnerabilities are discovered all the time and their significance is not always easy to work out.

·        Prevention measures

1.     Remove any components that you don't need.

2.     Consider using slightly less functional alternatives that you already have rather than something slightly better that requires another component.

3.     You should have configuration control on all of your components and know exactly what versions you are using rather than blindly updating things.

4.     You should keep on top of updates, especially security updates released for major components but this should be done in a controlled way and not just because an update is available.

5.     Use CVE database to look for known vulnerabilities using scanners

6.     Have a process to make urgent updates.

 

Unvalidated redirects and forwards

·        What is Unvalidated redirects?

1.     Any time that you forward the user to another URL based on what is passed into the request, you should check where you are being asked to redirect to.

2.     An attacker can pass in their own URL and make it look like the user has, for example, logged in to a real site and then gets redirected to a bad site that looks the same and asks them to e.g. "re-type" their password.

3.     Not very common but the dangers justify its appearance on the Top 10.

·        Prevention measures:

1.     Check all places in your code that redirect the user to another page and ensure that if the target URL is passed in, that it is checked suitably for your application e.g. is relative, only contains characters you expect to appear on internal links etc.