From 54724d579fca83224bb443d43b3eb13fe92651dc Mon Sep 17 00:00:00 2001 From: Christian Heinrich Date: Thu, 2 Jun 2022 03:51:04 -0400 Subject: [PATCH] Fix #474 in 2017 Release --- 2017/en/0xa1-injection.md | 1 - 1 file changed, 1 deletion(-) diff --git a/2017/en/0xa1-injection.md b/2017/en/0xa1-injection.md index 305b4f3e8..93c1a0ec0 100644 --- a/2017/en/0xa1-injection.md +++ b/2017/en/0xa1-injection.md @@ -23,7 +23,6 @@ Preventing injection requires keeping data separate from commands and queries. * The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). **Note**: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec(). * Use positive or "whitelist" server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. * For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. **Note**: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software. -* Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection. ## Example Attack Scenarios