The Open Web Application Security Project (OWASP) is a non for profit charity organisation that is focused on improving the security of software. OWASP was started in 2001 and meets regularly to discuss new and pervasive threats that exist online. Their most known initiative is the OWASP Top 10, which is aimed at raising awareness about application security by identifying some of the most critical risks facing organizations. This paper will elaborate on those risks in regards to the web and Ruby to explain why this is not enough to secure a website.

Figure 1. Shows the latest Top Ten OWASP Threats and Vulnerabilities of 2017

The OWASP is a great tool for general and widely used attacks however it is important to note that there are many thousands of attacks out there, so the OWASP is only useful to an extent. Command injection, listed as A1 on Figure 1 is not entirely related to Ruby on Rails but rather in the roots of Ruby itself. A command injection is an execution of arbitrary commands to the host system via an application through a http header, cookie or form. For the most part this is unlikely to happen on major frameworks however on rarely used Object Relational Models (ORM’s) it is still an issue. Looking at A2 on Figure 1 is Broken Authentication which is related to session management, another problem which has largely been solved due to the use of authentication libraries. It is unlikely for people to use their own because current ones are very well tried and tested. In regards to A3 on Figure 1 which is listed as Sensitive Data Exposure. This is something which is widely already adopted on most websites. The use of salting passwords, encrypting traffic by means of HTTPS and not caching sensitive data are just some to name a few. Broken access control is still an issue even in 2018 but for the most part can be easily corrected by using software such as CanCan which is a Ruby Gemfile. Broken access control is listed in part A5 on Figure 1 and basically asks the question “is a user authorised to be doing this?”. This is very common in Ruby and usually means the bad code will allow the updating of a model without checking whether the user is actually permitted to be doing that. Another way to check the access control of a piece of code in Ruby is to grep the codebase. This will give a rough idea of what models are being created, changed or removed. So this too can be avoided by simply applying due diligence when coding. In A9 of Figure 1, it mentions Using Components with Known Vulnerabilities. This is an example of something that can only be protected to an extent and the best hope is to constantly keep patching the code. It is far from a solved issue, but updates are all that can be done.  Therefore many of the OWASP Top 10 are issues which are generally known by the coding community and there exist, usable common solutions to them.  

It also has to be mentioned though that the OWASP and the top 10 list doesn’t include attacks such as server side request forgery (SSRF) which has been on the rise in recent years and is likely to become a much bigger issue in the future. Adding to that A6 on Figure 1 which is Sensitive Data Exposure doesn’t really seem to be a major issue as most people know to use only encryption and websites with HTTPS. In fact this might even be a bigger issue because of this reliance on always trusting sites with HTTPS are safe, which is certainly not true. Ruby on Rails for instance uses an OS encryption as well as the option for OpenSSL, plus a plethora of addons which will help with security. Therefore sensitive data exposure doesn’t need a place on this list as much as SSRF does. 

In conclusion, there is only so much one can do to protect and build a secure website. Nothing is ever absolutely secure and although the OWASP guidelines provide for a blueprint on allot of common attacks, this is quite literally the tip of the iceberg. One would be mistaken to think a site using OWASP and their top 10 list is immune to any danger. In saying that though it does cover the most common attacks likely to cause problems for a website. Many of the vulnerabilities such as A8 Insecure Deserialisation, which have seen a rise in recent years, and A10 Insufficient Logging and Monitoring, are issues which have often been ignored in previous years. The logging and monitoring is even more important because it’s something that is generally not well practiced in many coding companies and there is the natural impulse to try and prevent rather than center on other types of management. It is also worth noting that there isn’t a “security bible” that exists with every single computer vulnerability out there, and compiling a list would not be the most productive task out there as vulnerabilities are pervasive and constantly changing everyday. It would also be fair to say that this organisation is run by volunteers and therefore since there is no capital involved, there isn’t the resources available to have a dedicated team in order to search intensively for less well known or even unknown vulnerabilities.