Web Application Security

Posted by  Drupal Security Team  on  October 15, 2014 at 4:02pm Advisory ID: DRUPAL-SA-CORE-2014-005 Project:  Drupal core Version: 7.x Date: 2014-Oct-15 Security risk:  25/25 ( Highly Critical ) AC:None/A:None/CI:All/II:All/E:Exploit/TD:All Vulnerability: SQL Injection Description Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks. A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks. This vulnerability can be exploited by anonymous users. Update:  Multiple exploits have been reported in the wild following the release of this security advisory, and Drupal 7 sites which did not update soon after the advisory was released may be compromised. See this follow-...

Fake Data (Honey Data) By using honey data , it could help to identify attacks that are not triggered by error messages.  Honey data is data (e.g. Passwords, Credit card numbers,…) in tables which is never used by the application (Fake Ones). If someone from anywhere is accessing this kind of data , alert will be raised. Creation a table or tables containing unused data with juicy names (e.g. PASSWORD, CREDITCARD, SALARY).   Such interesting data is often the target of attackers.    During the attack, attackers are often accessing the view ALL_TAB_COLUMNS (Oracle) or INFORMATION_SCHEMA.COLUMNS (MySQL) to get the column names of interesting data.

SQL injection is  serious business , but you shouldn't be overwhelmed by the thought of defending against it. Follow these simple steps to keep attackers' eyes and fingers out of your databases. Ensure that only generic, nondescriptive error message or HTTP 500 pages are displayed to users. Never give away database metadata like table names or application source code snippets in error messages.  Validate simple input types like credit card numbers or postal codes with regular expression. If the input doesn't match the expected value, return an error to the user ( a generic, nondescriptive error!) and don't execute the database query. Always check to make sure that the input matches a good , valid pattern ( for example , whitelist pattern matching) rather than whether it matches a bad,invalid pattern(for example,blacklist matching). Whitelist validation defenses are usually much more resilient to newly discovered attack techniques.  If the input is a date or numer...