Pentesting RESTful webservices talks about problems penetration testers face while testing RESTful Webservices and REST based web applications. The presentation also talks about tools and techniques to do pentesting of RESTful webservices.
2. Hello
MI
MOHAMMED A. IMRAN
Application Security Engineer, CA Inc
Null Hyderabad Lead
OWASP Hyderabad Board Member
@MohammedAImran
Created and Designed using
3. LET’S TALK ABOUT ...
WHAT IS RESTful
WEB SERVICES?
PROBLEMS WITH REST
WS TESTING
TOOLS & TECHNIQUES
METHODOLOGY TO TEST
RESTful WS
8. Easy & Simple
GET /users/313/
VS
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.mysite.com/users">
<m:GetUserDetails>
<m:UserID>313</m:UserID>
</m:GetUserDetails>
</soap:Body>
</soap:Envelope>
9. Light weight
{
"login": "MohammedAImran",
"type": "User",
"site_admin": false,
"name": "Mohammed A. Imran",
"company": "CA Inc",
"email": "morpheus@null.co.in"
}
<soap:Body xmlns:m="http://www.mysite.com/users">
<m:GetUserDetailsResponse>
<m:UserName>MohammedAImran</m:UserName>
<m:Type>user</m:Type>
VS
<m:SiteAdmin>false</m:SiteAdmin>
<m:UserName>Mohammed A.Imran</m:UserName>
<m:Company>CA Inc</m:Company>
<m:Email> morpheus@null.co.in </m:Email>
</m:GetUserDetailsResponse>
</soap:Body>
Note: REST can also use XML as media type
10. Many more reasons to use ...
●
Easy to understand & document
●
Easy on limited bandwidth
●
READS can be cached and hence reduces the bandwidth
●
Better browser support since data format mostly is json
●
Can be used by mobile devices
●
Loosely coupled
12. “
Representational state transfer (REST) is an
architectural style consisting of a coordinated
set of constraints applied to components,
connectors, and data elements, within a
distributed hypermedia system.
13. What ? Let me explain ...
REST is an architectural style with some imposed constraints
in how data is accessed and represented while developing web
services or applications. It uses HTTP 1.1 as inspiration.
34. Status Codes
200 OK
201 Created
204 No Content
304 Not Modified
500 Internal Server Error
501 Not Implemented
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
409 Conflict
36. Difficulty in doing REST PT
●
Many JSON variables to fuzz and difficult to find which ones
are optional and to be fuzzed
●
Custom authentication
●
Statelessness
●
Non common HTTP status codes which tools are used to
37. Difficulty in doing REST PT ...
●
●
●
Not so good automated tool support
Every API is different from other and hence need custom
tweaking for tools
Heavy reliance on Ajax frameworks for creating PUT and
DELETE requests as most browsers don’t support them
41. Authentication ...
●
REST APIs rely heavily on SSL
●
Often basic authentication is coupled with SSL ( Bruteforce ? )
●
Often custom token authentication schemes are built and used
( a sure recipe for disaster)
●
Never pass username/password, tokens, keys in URL
(use POST instead )
●
Implementing authentication tokens in Headers takes away headache of
having a CSRF token
42. Session Management
●
Check all session based attacks on tokens as well
●
Session timeout
●
Session brute force
●
●
Generally tokens are stored in local storage of browsers,
make sure you delete the token after log-out and upon
browser window close
Invalidate the token at server side upon on logout
43. Authorization
●
Privilege escalation (Horizontal and Vertical)
●
Make sure there is a tight access control on DELETE, PUT methods
●
Use role based authentication
●
●
Since usually the consumers of the REST APIs are machines, there
are no checks if service is heavily used, could lead to DoS or
BruteForce.
Protect administrative functionality
46. NOTE
All attacks which are possible on any web application are possible with
REST APIs as well.
47. Input Validation
●
SQL Injection
●
XSS
●
Command Injection
●
XPATH Injection
However XSS becomes difficult to fuzz because of JSON
and you might want to scan with sql injection and xss
profiles separately
48. Output encoding
●
If you application has a web interface then might want to use
the following headers:
X-Content-Type-Options: nosniff
– X-Frame-Options: DENY/SAMEORIGIN/ALLOW-FROM
JSON Encoding
–
●
49. Cryptography
●
●
Use TLS with good key size (384 bits preferably)
Use client side certificates possible however not usually seen
for APIs
●
Use strong hashing algorithms(scrypt/bcrypt/SHA512)
●
Use strong encryption mechanisms (AES)
50. Few notes ...
●
●
●
●
Use proxy to determine the attack surface and to understand
the application
Identify URLs, Resources, status codes and data needed
Every part of the http protocol is potential for fuzzing in
RESTful APIs (dont forget headers)
WAF evasion is possible since json is not well understood by
WAFs
53. cURL Primer
cURL
-b or - -cookie ”COOKIE HERE”
-h or - -header “Authorization: Custom SW1yYW5XYXNIZXJlCg==”
-X or - -request PUT/POST/DELETE
-i or - -include //include response headers
-d or - -data “username=imran&password=Imran” or - -data @filecontaining-data
-x or - - proxy 127.0.0.1:8080
-A or - -user-agent ”Firefox 27.0”
54. cURL Primer ...
●
●
●
cURL is great for automation if you know how service works.
cURL libraries are available for majority of the languages like php, python
and many more...
You can perform complex operations and script them pretty fast.
55. cURL Examples
#!/bin/bash
users="Imran Jaya Raghu Vinayak"
for dirName in $users
do
curl -i -H “Authorization: Custom SW1yYW5XYXNIZXJlCg==”
"http://www.mysite.com/users/$dirName" --proxy 127.0.0.1:8080
done
58. Firefox Add-on ...
●
●
If you need graphical interface, browser add-ons provide GUI, however not
as powerful as the cURL command.
Specialized developer tools ( SOAP UI ) can also be used for testing.