4.0

More documents

Recommendations

Info

130 Web Application Penetration Testing possible to extract the first character of the username on a specifically selected row. As the inner query returns a set of records, and not just one, it is not possible to use it directly. Fortunately, we can combine multiple functions to extract a specific string. Let’s assume that we want to retrieve the username of the 10th row. First, we can use the TOP function to select the first ten rows using the following query: SELECT TOP 10 username FROM users Then, using this subset, we can extract the last row by using the LAST function. Once we have only one row and exactly the row containing our string, we can use the IFF, MID and LAST functions to infer the actual value of the username. In our example, we employ IFF to return a number or a string. Using this trick, we can distinguish whether we have a true response or not, by observing application error responses. As id is numeric, the comparison with a string results in a SQL error that can be potentially leaked by 500 Internal Server Error pages. Otherwise, a standard 200 OK page will be likely returned. For example, we can have the following query: http: /www.example.com/index.php?id=’%20AND%20 1=0%20OR%20’a’=IIF((select%20MID(LAST(username),1,1)%20from%20(select%20TOP%2010%20username%20from%20users))=’a’,’a’,’b’)%00 that is TRUE if the first character is ‘a’ or false otherwise. As mentioned, this method allows to infer the value of arbitrary strings within the database: [1] By trying all printable values, until we find a match [2] By inferring the length of the string using the LEN function, or by simply stopping after we have found all characters Time-based blind SQL injections are also possible by abusing heavy queries. References • http: /nibblesec.org/files/MSAccessSQLi/MSAccessSQLi.html • http: /packetstormsecurity.com/files/65967/Access-Through- Access.pdf.html • http: /seclists.org/pen-test/2003/May/74 • http: /www.techonthenet.com/access/functions/index_ alpha.php • http: /en.wikipedia.org/wiki/Microsoft_Access Testing for NoSQL injection Summary NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren’t using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[1] language , rather than in the declarative[2] SQL language, the potential impacts are greater than traditional SQL injection. NoSQL database calls are written in the application’s programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as < > & ; will not prevent attacks against a JSON API, where special characters include / { } : . There are now over 150 NoSQL databases available[3] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests. NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call. Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing. At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs. How to Test Testing for NoSQL injection vulnerabilities in MongoDB: The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[4] The most commonly used API call allowing arbitrary JavaScript input is the $where operator. The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL. db.myCollection.find( { $where: “this.credits == this.debits” } ); Optionally JavaScript is also evaluated to allow more advanced conditions. db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); Example 1 If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed
131 Web Application Penetration Testing directly into the MongoDB query without sanitization. b.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );; As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error. ‘ “ \ ; { } With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript. This input 0;var date=new Date(); do{curDate = new Date();} while(curDate-date
Page 1 and 2:
1 Testing Guide 4.0 Project Leaders
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3 Testing Guide Foreword - Table of
Page 7 and 8:
5 Testing Guide Foreword - By Eoin
Page 9 and 10:
7 Testing Guide Frontispiece 1 Test
Page 11 and 12:
9 Testing Guide Introduction 2 The
Page 13 and 14:
11 Testing Guide Introduction vide
Page 15 and 16:
13 Testing Guide Introduction Testi
Page 17 and 18:
15 Testing Guide Introduction laid
Page 19 and 20:
17 Testing Guide Introduction valid
Page 21 and 22:
19 Testing Guide Introduction USER
Page 23 and 24:
21 Testing Guide Introduction ment
Page 25 and 26:
23 Testing Guide Introduction offen
Page 27 and 28:
25 The OWASP Testing Framework sect
Page 29 and 30:
27 Web Application Penetration Test
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82: 79 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 131: 129 Web Application Penetration Tes
Page 183 and 184:
181 Web Application Penetration Tes
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
209 same code can be applied to ses
Page 213 and 214:
211 Reporting Test ID Lowest versio
Page 215 and 216:
213 Reporting Test ID Business Logi
Page 217 and 218:
215 Appendix kajfghlhfkcocafkcjlajl
Page 219 and 220:
217 Appendix Testing - http:/www.ni
Page 221 and 222:
219 Cross Site Scripting (XSS) For
Page 223 and 224:
221 LDAP Injection For details on L
show all

4.0

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?