SQL Injection: The Longest Running Sequel in Programming History

One of the risks to a company operating a public-facing website with a Structure Query Language (SQL) database is an attacker exploiting the SQL injection vulnerability. An attacker can cause an SQL database to perform actions that the developer did not intend like revealing, modifying, or deleting sensitive data. This can cause a loss of confidentiality, integrity, and availability of information in a company’s database, and it can lead to severe costs of up to $196,000 per successful injection attack (NTT Group, 2014). This paper discusses the history of the SQL injection vulnerability, focusing on: How an attacker can exploit the SQL injection vulnerability When the SQL injection attack first appeared How the attack has changed over the years Current techniques to defend adequately against the attack The SQL injection vulnerability has been known for over seventeen (17) years, and the countermeasures are relatively simple compared to countermeasures for other threats like malware and viruses. The focus on security-minded programming can help prevent a successful SQL injection attack and avoid loss of competitive edge, regulatory fines and loss of reputation among an organization’s customers

SCRAMBLE-CFI: Mitigating Fault-Induced Control-Flow Attacks on OpenTitan

Secure elements physically exposed to adversaries are frequently targeted by fault attacks. These attacks can be utilized to hijack the control-flow of software allowing the attacker to bypass security measures, extract sensitive data, or gain full code execution. In this paper, we systematically analyze the threat vector of fault-induced control-flow manipulations on the open-source OpenTitan secure element. Our thorough analysis reveals that current countermeasures of this chip either induce large area overheads or still cannot prevent the attacker from exploiting the identified threats. In this context, we introduce SCRAMBLE-CFI, an encryption-based control-flow integrity scheme utilizing existing hardware features of OpenTitan. SCRAMBLE-CFI confines, with minimal hardware overhead, the impact of fault-induced control-flow attacks by encrypting each function with a different encryption tweak at load-time. At runtime, code only can be successfully decrypted when the correct decryption tweak is active. We open-source our hardware changes and release our LLVM toolchain automatically protecting programs. Our analysis shows that SCRAMBLE-CFI complementarily enhances security guarantees of OpenTitan with a negligible hardware overhead of less than 3.97 % and a runtime overhead of 7.02 % for the Embench-IoT benchmarks.Comment: Accepted at GLSVLSI'2