2

In my experience, SQL Injection is always a threat. If bad actors don't penetrate via SQL, they get enough data to launch bruteforces via MBASentry or do privilege escalation via scripts. However, I browse e-mercenary sites like https://2captcha.com/ and notice they support virtually every API other then Ruby.

The core of my question is the following: does Ruby along with additional provide enough protection to warrant not using additional measures.

  • 1
    "I browse e-mercenary sites like https://2captcha.com/ notice they support virtually every API other than Ruby" That just means you can't (easily) write a script in Ruby that uses their API to solve captcahs. It _doesn't_ mean you can't use their service to attack sites with backends written using Ruby. – Ajedi32 Jul 26 '16 at 20:31
  • 1
    Also, Ruby is just a programming language. It's completely unrelated to SQL and therefore no more or less vulnerable than any other programming language to SQL injection attacks. Ruby **on Rails** is a web application framework that does have some protections against SQL injection, but that doesn't mean it's not *possible* to write an application with Ruby on Rails that has a SQL injection vulnerability. – Ajedi32 Jul 26 '16 at 20:33

1 Answers1

1

No all security measures have weaknesses at points in time. You always want to have layers of Defense-in-Depth and never rely only on a single security control.

A deeper comparison of how the two you mention perform may or may not reveal whether there is overlap in the protection mechanisms. It may or may not turn out to be that one of them completely overlaps the other such that the second may not appear to be providing much benefit at the time of analysis.

If both are actively being developed there will be many points in time where one solution eclipses the other such that having both will provide more protection than one by itself. Depending on the ecosystems for that product this may happen frequently.

My suggestion would be to do a deep evaluation of each product, learn how frequently they get updates (look at their past history if possible), and see if you can determine what all each of them are effective at blocking. If this is a new market you may want to re-evaluate them every few months in case one becomes much better than the other.

Finally, if possible it's better to have two totally different types of security controls rather than two controls of the same type. The reason this helps is if new classes of attacks completely void one type of defense there may be a situation where a secondary type of defense may still work. Likewise in many, but not all cases, it's helpful if the security control is running on a system in front of the server containing data being protected rather than on that system (if the control itself has a bug it doesn't drop the attacker on the box with the data).

Trey Blalock
  • 14,099
  • 6
  • 43
  • 49