OWASP means Open Web Application Security Project. The OWASP is a not-for-profit organization registered in the USA since 2004, whose goal is to secure Internet applications and thus, the users of these applications / websites.
After 10 years of activity, the OWASP TOP 10 of the most common online threats became a reference in the field of security.
Here is its 2013 version (last one out when this article was published):
OWASP TOP 10 ANALYSIS
All threats are not necessarily explicit without any explanations or examples. (The explanations written by the OWASP are available here, in many language.)
A1 – Injection (our detailed article here)
The most common injections are SQL related, even though SQL is not the only language used. It entails injecting SQL language into, for instance, a web form. The easiest injection consists in writing “admin” in the login field and entering, instead of the password, a SQL request that will contain the characters ‘ or 1=1. The website will then forward the MySQL request to the database. The “OR” permits to say to the database that if the password is right or if 1=1 is true (which is always the case), then the access is open. Thus, even if the password is wrong, the 1=1 part of it remains always true and the pirate will be able to access the database.
It is an old, simplistic example, but the concept is here. Many more examples are available here.
A2 – Broken Authentication and Session Management (our detailed article here)
The easiest example involves an URL containing session identifiers, which one sends to a friend via email. If the server does not check a complementary element, the second person will be able to use the account of the first person as if he or she was logged in. Generally speaking, it is important to work closely on the session mechanisms in order to avoid this kind of impersonalization, to encrypt passwords, to deny weak (insecure) passwords, etc… “Name”, “qwerty”, “1234” or “letmein” are no decent passwords. Avoid the name of your children, dates or license plates numbers.
A3 – Cross Site Scripting (our detailed article here)
A4 – Insecure Direct Object References (our detailed article here)
It is frequent for a website to include in a page resources that came from another data frame of reference. This has to be done through the mediation of a secure access or a filtration, to avoid the inclusion of unauthorized resources to be included. However, these dialog securing methods must not be readable or available by looking at the used URLS or pages’ source code.
A5 – Security Misconfiguration (our detailed article here)
Cette catégorie est très vaste car elle recouvre des sujets d’horizons très différents. Les services de la plateforme sont-ils à jour, bien protégés, par des mots de passes suffisamment solides ? Les configurations sont-elles ajustées pour éviter qu’une information importante ne soit divulguée ou accessible par erreur, le filtrage des ressources est-il bien effectué, les services inutiles ont-ils été coupés, etc. C’est un ensemble qui nécessite un travail à plusieurs mains, celles des administrateurs et celles des développeursThis category is very large since it covers subjects from very wide horizons. Are the platform’s services, to this day, well protected by strong enough passwords? Are configurations adjusted to prevent an important information from being divulged or mistakenly accessible? Are resources well filtered, useless services stopped, etc…? It is a whole that needs the multi-handed work of both administrators and developers.
A6 – Sensitive Data Exposure (our detailed article here)
The OWASP mainly emphasizes on the data encoding. If they are sensitive, they must be protected by an encoding to avoid a clear access. But in our mind, it goes beyond. One must not, for instance, keep information that is not useful. In the same way, one must ensure that all sensitive data is inaccessible from the outside, or that it is not possible to integrate them in web pages by forging requests.
A7 – Missing Function Level Access Control (our detailed article here)
The basic idea is to never rely on a security hosted on the client’s side, for example his browser. By default, the browser must be considered as hostile and as reporting false information, in case an attacker decided to do just that or had taken control over the browser of a victim.
If a user can go from the step of booking a flight straight to the choice of his place in the plane without going through the paying step, there is a vulnerability on the website. In the same way, if it is possible to call pages or functionalities without going through some checking phases and that those should never be called by visitors, there is a lack of access control in the functioning level.
Security and its mechanisms should be handled in a controlled environment: the one of the server.
A8 – Cross-Site Request Forgery (our detailed article here)
This vulnerability type, also called CSRF, is linked to the fact that browsers automatically send session cookies and a number of other information. It then becomes possible for an attacker to forge an answer to a request (often a web form) and to lead the user towards a page of his choice, hosted on another website that is under his control. To illustrate the problem, let us imagine that a person is authenticated on his bank’s website, that we will call A.
Let us still imagine that this person goes then to another website that we will call B. If the bank (A) of this person stores the cookie (without an expiration date), the site B will be able to call a page of the site A within itself and to reuse the id of the visitors without having to relog. This can apply to a back office or, for instance, any site using the “remember me” button for instance.
A9 – Using components with known vulnerabilities (our detailed article here)
This category is a very explicit one. Softwares know life cycles, some novelties give rise to security vulnerabilities, some of which are kept “secret” by the people or companies who find them. Sometimes they are not seen discovered before months or years. The fact remains that software components that haven’t known any vulnerability can be counted on the fingers of one hand; repeat offenders, however, are legion.
A10 – Unvalidated Redirects and Forwards (our detailed article here)
This category covers attacks that are lead during redirects. Typically, 30x HTTP codes are used to redirect a user from a page to another, depending on some parameters. If the destination URL of the redirect is put as a parameter in the original page URL, then an attacker could modify this redirection by changing the URL which was put as a parameter. It would give him have access to another URL. An example (from the OWASP description): if the URL is http://www.example.com/redirect.jsp?url=evil.com, the attacker will be able to redirect to evil.com and if the URL is http://www.example.com/boring.jsp?fwd=admin.jsp then he will be able to redirect himself towards admin.jsp, a page he should not have access to.
Of cource, it is very possible, and even classic, to combine those different flaws.
CerberHost can protect your website against all those vulnerabilities. For more details about the protections displayed by the CerberHost solution, come and discover its presentation video HERE