-
O gabarito é a letra E.
Uma das ferramentas para o suporte a prevenção do SQL Injection é o SQL INJECTION ME: Plugin do Firefox que através do submit de seus formulários acusa se há ou não abertura para o uso de instruções SQL nos mesmos. Alguém mal intencionado pode usar seu formulário de login, por exemplo, para resgatar os dados de acesso de usuários de seu banco para acessar o sistema e modificar seus dados ou obter alguma informação importante.
Podemos citar também a utilização de expressões regulares em seus códigos para “limpar” as variáveis enviadas para o sistema.
Outro método utilizado por programadores na prevenção de invasões através de comandos SQL é a utilização do PDO (PHP Data Objects) na camada de abstração da aplicação. Esse tipo de recurso é bastante útil e fácil de implementar, além de aumentar a portabilidade entre banco de dados sem muita ou quase nenhuma alteração de instruções SQL.
O PDO utiliza “prepared statements” na formação de suas queries. O que nada mais é que um template que irá nos ajudar a escrever uma instrução. Porque isso ajuda a prevenir ataques de injeção de SQL? Como é um “template”, a estrutura nos permite saber onde exatamente irão entrar os valores para as nossas queries.
-
Prepared statements and stored procedures
http://php.net/manual/pt_BR/pdo.prepared-statements.php
-
Letra E
Olhe abaixo a mesma questão da banca, em 2015, mas por um olhar invertido:
Ano: 2015
Banca: FCC
Órgão: TRE-RR
Prova: Técnico Judiciário - Operação de Computadores
Considere o texto abaixo.
A melhor forma para descobrir se uma aplicação está vulnerável a este tipo de ataque é verificar se todos os usos dos interpretadores separam claramente os dados não confiáveis do comando ou consulta. Para chamadas em linguagem estruturada de consulta, isso significa utilizar variáveis de ligação em todas as instruções preparadas e procedimentos armazenados, e evitar consultas dinâmicas.
O tipo de ataque citado no texto é conhecido como
a)Key Logging.
b)Buffer overflow.
c)SQL Injection.
d)Cross-Site Scripting (XSS).
e)Cross-Site Request Forgery (CSRF).
-
Primary Defenses
Defense Option 1: Prepared Statements (with Parameterized Queries)
The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.
Defense Option 2: Stored Procedures
Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.
Defense Option 3: White List Input Validation
Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.
Defense Option 4: Escaping All User-Supplied Input
This technique should only be used as a last resort, when none of the above are feasible.
This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective.
Fonte: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
-
As técnicas para se evitar as vulnerabilidades de SQL injection incluem:
· Consultas parametrizadas ou procedimentos armazenados (stored procedures), que incluem a utilização de prepared statements (comandos pré-preparados);
· Filtragem de entradas; e
· Segurança de funções.
Assim, a única alternativa que contém técnicas presentes nesse rol é a letra E.
Gabarito: E