Made by the shielded test site indicate vulnerability as well
http://www.mysite.com/chat/client.php?locale=pt-br&style=silver&url=http%3A//www.mysite.com/&referrer=
MENSAGEM
No response from server. Injectable request #: 1 Injected item: GET: referrer Injection value: " or 1=1 -- -
HOW IT WORKS
SQL Disclosure is a special kind of a SQL Injection vulnerability. SQL Injection is a type of attack that allows a remote user to pass SQL
(Structured Query Language) commands and strings to a back-end database. By exploiting SQL injection vulnerabilities an attacker can
gain access to sensitive information and potentially gain full control over the system on which the database is installed. An attacker may
make use of a SQL Disclosure vulnerability to gain sensitive information without having the required privileges or to locate generic SQL
Injection vulnerabilities. He starts by trying to cause an error in the processing of a SQL query, thereby generating a SQL exception. If
such exceptions are suppressed by the application, he may use the Blind SQL technique to locate a SQL Injection vulnerability. This
enables him to guess the correct structure of the query. For example, if an injection with the construct " -- - causes an exception but with
';# does not, then he understands that the query ends in a ' . Next, he chooses an appropriate SQL statement, for example ' or 1=1;# ,
which will always result in a true state and uses this in the input. When this modified query gets executed, the attacker stands to gain
sensitive information not available to him otherwise. Exploit A SQL Disclosure vulnerability, by definition, involves disclosure of
information to users without sufficient privileges by way of a SQL Injection. Hence, the disclosure of this extra information may be
considered as an exploit of this vulnerability. In this sense, this attack is itself an exploit of a generic SQL Injection vulnerability.
IMPACT
A SQL Disclosure vulnerability enables an attacker to gain access to information that he does not have the privileges for. This includes
data stored in the tables and probably credentials for accessing sections of an application requiring higher privileges. Many Web
applications store important information in SQL databases, such as financial transactions of users, confidential company records and
credit card numbers. Querying such databases without proper access restrictions can cause leakage of this data to anyone who can send
queries to them through a Web application. For example, a well-crafted injection on a banking application may reveal transactions done
by all users to one malicious user. Similarly, an injection on an application used for taxation by companies may expose tax details of many
companies to an attacker.
SOLUÇÃO
The following recommendations will help to mitigate the risk of SQL injection attacks: * Monitor your production applications for the
latest security vulnerabilities and bugs. * Keep up to date on patches and security fixes as they are released by the vendor or
maintainer. * Limit the types of characters and strings that can be passed as application parameters by configuring native application
filters. * Avoid using external SQL interpreters. * Audit your applications frequently at points where HTML input can reach SQL
interpreters. * Ensure proper input validation is performed wherever user supplied data is used, regardless of the application's
relationship to a back-end database. * Avoid using dynamic SQL or PL/SQL and use bound variables whenever possible. *
Enforce strict limitations on the rights to database access. * Remove any sample applications or demo scripts that allow remote
database queries. The following ASP.NET code shows a simple example of a SQL disclosure vulnerability. Assume the goal of the code
is to query user account details, such as name, account id, and credit card, from a users PIN number. SqlDataAdapter myCommand =
new SqlDataAdapter( "SELECT usr_name, usr_accntid, usr_cc FROM accounts WHERE usr_pin = '" + PIN.Text + "'",
myConnection); Assuming a PIN id of 10012301, the code above results in the following SQL query: SELECT usr_name, usr_accntid,
usr_cc FROM accounts WHERE usr_pin = '10012301' The insertion of special characters allows a remote attacker to manipulate the SQL
query and thus substitute or append additional queries in the place of the expected value. This allows a malicious user to craft arbitrary
SQL expressions and have them executed against the database. For example, the query "1000' or 1=1--" would allow the attacker to
enumerate the name, account id, and credit card number of every user in the accounts table, in virtue of the following SQL expression:
SELECT usr_name, usr_accntid, usr_cc FROM accounts WHERE usr_pin = '1000' or 1=1 --' To prevent SQL Injection type attacks, you
should consider adopting the following practices: ASP.NET * Use the RegularExpressionValidator and RangeValidator to ensure
that input data conforms to the expected type and format. If using HTML input controls, use the Regex class (in the
System.Text.RegularExpressions namespace) in your server-side code to constrain user input to allowable types and expected format.
- Establish and enforce rules for allowable input and reject data that does not conform to your defined safe input. * Consider
executing all queries as parameters with stored procedures. The use of parameters helps to prevent insertion of apostrophes and
hyphens. Note, merely using stored procedures does not prevent SQL injection-based attacks. * Enforce length limits on inputs, and
reject input that is longer than the specified length. This practice can make SQL injection vulnerabilities more difficult to exploit. *
Validate the number of rows that are expected to be returned by a particular query. Produce exceptions if more rows than the expected
value are returned by the query type. * Perform input validation on both the client and server. Do not rely on client-side code to ensure
safe inputs. Ensure your input validation routines include server- side code that also validates input against a set of safe or expected
characters and formats. PHP * Use addslashes() to escape SQL queries. * Employ input validation to against a set of
allowable characters and reject input which deviates from this pattern. * If you are using MySQL with PHP, use
mysql_real_escape_string() to escape SQL queries. Be advised, this function does not escape MySQL wildcard characters, such as % or
, which will need to be sanitized separately by input validation routines. * Enforce length limitations on input so that inputs longer than
the expected length are rejected. Java The risk associated with SQL injection can be mitigated to a large extent in Java by the use of
prepared statements or a combination of stored procedures and callable statements. Input validation is still required apart from these
techniques. **Vulnerable Code** Consider a typical implementation of a SQL query in Java: String username =
httpRequest.getParameter("username"); String sqlQuery = "SELECT * FROM users WHERE userid = '" + username + '"; Statememt stmt
= db_conn.createStatement(sqlQuery); ResultSet results = stmt.executeQuery(); In this code, the input "username" from an
HttpServletRequest object is directly used in a live SQL query. A user could give potentially harmful input in the field username in the web
application to compromise it. Secure Code Input Validation Any input such as that mentioned above should always be
validated before being used in a SQL query. The validation code looks like this: if () String sqlQuery = "SELECT * FROM users
WHERE userid = '" + username + '"; else throw new IllegalArgumentException(); Here, if () could be a simple length check, such as: if
(username.length() < MAX_POSSIBLE_LENGTH) or, it could amount to a more elaborate regular expression match, for example, for
peoples' first names: if ( username.matches("[0-9a- zA-Z']") ) or, an even more elaborate regular expression, for peoples' e-mail
addresses: if ( username.matches("n[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}n") ) This means that no input other than what is exactly
expected is passed to the SQL query. This ensures that even if an attacker injects SQL into input fields, it never reaches the database
server. When using regular expressions, they must be tweaked to represent the exact format of input expected. _Prepared
Statements* Prepared statements are used to send pre-compiled SQL queries to a database server, in the absence of stored
procedures. In Java, PreparedStatement objects can be used for this purpose with one or more parameters. This is implemented as
follows: String username = httpRequest.getParameter("username"); String query = "SELECT * FROM users WHERE userid = ?";
PreparedStatement stmt = db_conn.prepareStatement(query); stmt.setString(1, username); ResultSet results = stmt.executeQuery(); The
"?" in the SQL query is a placeholder for parameters to go in. These parameters are set using set---() methods of the PreparedStatement
object, e.g., setString(), as shown. When a prepared statement is used, the database server uses the value of the variable bound to the
"?" provided "as is," i.e., without interpreting any SQL syntax in it. So, if an attacker provides username "name' or 1=1 -- -", the database
looks for the user with "name' or 1=1 -- -" as a name, which does not return any results and the attack fails. Stored Procedures and
Callable Statements A stored procedure is a group of SQL statements which performs a specific task. These groups are entities with
the database server, which can be called like SQL queries. CallableStatement objects in Java are used to call such stored procedures in
a safe way, like PreparedStatement objects for simple SQL queries. CallableStatement objects are used as follows: String username =
httpRequest.getParameter("username"); CallableStatement cstmt = db_conn.prepareCall("{call findLogin(?,?}");
cstmt.setString(1,username); cstmt.registerOutParameter(2,Types.TIMESTAMP); cstmt.executeQuery(); String lastLogin =
cstmt.getTimestamp(2).toString(); Similar to prepared statements, the database server uses the value bound to the "?" provided as is. So,
the injection fails. The key to the prevention of SQL injection that leads to vulnerabilities such as SQL disclosure and blind SQL injection is
a combination of all the methods described above. No one method by itself can provide fool-proof protection against SQL injection
attacks. ColdFusion Generic ColdFusion provides a number of ways to filter or validate user input. The security measures span
both client-side and server-side filtering. Where possible, implement your security controls on the server-side to avoid tampering of your
controls via a Man-In-The-Middle (MITM) proxy. An attacker can easily bypass client-side controls by using such a program to modify the
underlying HTTP Request as it passes between the proxy and the web application. Additionally, we recommend that sites using
ColdFusion should configure their application using the recommended security features of the Adobe ColdFusion 8 Developers Guide, or
the guide relevant to your version of ColdFusion. ColdFusion Data validation allows you to control the type of data that is allowed as well
as to ensure that user- supplied data corresponds to the correct form. Attentive data validation procedures can have the following
benefits: * Enhance the security of your application by ensuring that malicious users cannot input data that exploits a security
vulnerability, such as SQL Injection, XSS, or buffer overflows. * Enhance application resilience by rejecting invalid data on the
server-side prior to processing the input. * Enhance application usability by providing the user with feedback that allows them to
correct their mistakes, while not generating verbose error messages. The list below gives you an overview of the available data validation
tags, as well as their validation type (server vs. client side) methods. For a more detailed explanation consult your ColdFusion Developers
resources on the CFML language and its security features: * Mask, client: Applies to cfinput tags on the client-side. The use of
Mask creates a JavaScript or ActionScript control that verifies that input corresponds to a specified pattern. For example: nnn-nnn-nnnn
where "n" is an integer. Note, this is a client-side control that can be easily bypassed. * _onBlur, _client: Applies to cfinput and
cftextarea tags. _onBlur creates a JavaScript that runs in the browser and checks that user supplied data matches a corresponding
pattern. This can be bypassed by a Man- In-The-Middle (MITM) proxy. * onSubmit**, **client: Applies to the Web browser
when the user clicks submit and checks that the data passed from the browser corresponds to a specified pattern. This can be bypassed
by MITM proxy. * onServer,** _**server: Applies to server-side data after the form is submitted. ColdFusion checks the form
data of cfinput and cftextarea tags and generates an error page if the data is not valid. Use this tag in conjunction with the cferror tag to
specify the validation error page. Note: a failure to specify an error page will result in an information leak in your error handling routine, as
ColdFusion errors are verbose. * IsValid, **server: Tests an input variable to determine if the content of the variable meets internal
validation rules. The **IsValid function returns true or false for the variable. * _Cfparam, _**server: **Tests an input variable to
determine if the variable meets validation criteria. If the variable does not meet the criteria an expression exception is generated. *
_Cfqueryparam, _**server: **Evaluates the content of a HTTP query string to validate whether the string meets validation criteria. This
tag is useful for scrubbing HTTP query strings prior to further processing. SQL Security When data from a user-supplied parameter
is passed within a SQL query, if proper security mechanisms are not in place a malicious user can modify the underlying query and
conduct SQL Injection attacks. Vulnerable Code Consider the code below, which is vulnerable to SQL Injection: SELECT
FirstName, LastName, From Members WHERE EmpID='#Form.EmpID#' The sample code above could be called by a malicious URL
Page 5
in the following way: Server/script.cfm?EmpID=0%20Malicious%20SQL%20Query Which would result in following SQL Expression, as if
the form consisted of: SELECT FirstName, LastName, From Members WHERE EmpID= 0 MALICIOUS SQL QUERY An attacker
could abuse this vulnerability to delete all data from tables or read or modify the underlying database, or authenticate without a username
or password. Secure Code The cfqueryparam tag can be used to evaluate the string parameters prior to processing by the
database. You can specify the type of data for the corresponding database columns used in the select statement and reject input of
invalid data types. Cfqueryparam, when used in conjunction with cfsqltype, can also use a wide range of input validation functions, as
well as constrain the length of input on the server- side, preventing SQL Injection. For example: SELECT * FROM Employees WHERE
EmpID = This code thus prevents SQL Injection of the EmpID parameter value by enforcing an integer data type. Note that you must
enforce proper error handling or this security measure could introduce an information leak via verbose SQL Error Messages. When
manipulating strings, you can use other security measures to enforce a string data type, limit maximum length of the string, and escape
the string values within single quotations to ensure it is examined as a single value by the database. For additional information on the use
of cfqueryparam and cfsqltype, consult your ColdFusion documentation. In addition to the use of these measures, you should also enforce
input validation to reject queries that contain special characters. This prevents an attacker from manipulating SQL expressions via special
characters used by delimiters in database queries.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent