The commit shows a software developer using the name Fosco Marotto introducing precisely the type of rookie mistake that could lead to the kind of breach reported this weekend. Specifically, line 23 strips the code of “reject” and “filter,” which are API functions that implement a programming idiom that protects against SQL injection attacks. This idiom allows programmers to compose an SQL query in a safe way that “sanitizes” the inputs that website visitors enter into search boxes and other web fields to ensure that any malicious commands are stripped out before the text is passed to backend servers. In their place, the developer added a call to the Rails function that contains the “find_by_sql” method, which accepts unsanitized inputs directly in a query string. Rails is a widely used website development toolkit.
“Sadly Rails documentation doesn’t warn you about this pitfall, but if you know anything at all about using SQL databases in web applications, you’d have heard of SQL injection, and it’s not hard to come across warnings that find_by_sql method is not safe,” Dmitry Borodaenko, a former production engineer at Facebook who brought the commit to my attention wrote in an email. “It is not 100% confirmed that this is the vulnerability that was used in the Gab data breach, but it definitely could have been, and this code change is reverted in the most recent commit that was present in their GitLab repository before they took it offline.” Ironically, Fosco in 2012 warned fellow programmers to use parameterized queries to prevent SQL injection vulnerabilities.
Read more of this story at Slashdot.