I was playing with Ruby and tried HTTP4e on MyRadRails and it worked as a charm.
This is what I call write once run anywhere. Great job Eclipse!
Recently I had to explain how would I design a REST Authentication. My humble thoughts:
Using Basic or Digest is naive.
1. Basic token is a plain Base64 text. To make it worst, you need to send the username and password each time as part of the HTTP packet so any MitM attacker will be able to translate it.
2. The security aspect could be resolved by using Basic over SSL. Yet SSL has it’s performance drawbacks. And in your requirements SSL may not be an option.
3. Using the Digest as being secure, resolves 1 and 2, yet it has disadvantages as:
- The nonce is optional. Skipping the nonce MD5(username:nonce:password) could end up with Digest algorithm of MD5(username:password) which is not secure for simple passwords. Any computer today would be able to reverse engineer a simple password MD5 hash using available dictionaries.
- The Digest is optional. A MitM could tamper the packet and browser could fall back to Basic.
4. Digest and Basic when invoked within a browser environment has the annoying feature of opening a native popup with username/password.
5. Basic/Digest don’t expire. As long as you stole a Basic/Digest security token you can continue with the replay attack.
6. No prevention for tampering. Digest algorithm includes hashing the URI:Method:andBody yet, those algorithms are once again recommendations only and optional.
My prefer approach would be a
Custom Authentication Token a la Amazon
Amazon REST Authentication did a great job of providing a secure REST Authentication. Let’s dissect their token:
Example AWS Call:
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000 Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
where Authorization algorithm header is:
Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;
and signature:
Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );
and more:
StringToSign = HTTP-Verb + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource; CanonicalizedResource = [ "/" + Bucket ] + <HTTP-Request-URI, from the protocol name up to the query string> + [ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"]; CanonicalizedAmzHeaders = <described below>
Explaining:
- CanonicalizedAmzHeaders: Some special AWS business headers. Skipping..
- CanonicalizedResource: a string concatenating elements from HTTP packet being sent – URI, parameters, Method etc. Reason? Preventing HTTP packet tampering. Assuming an attacker stole the Authentication token, then stolen token could be used only within the current REST call as vital elements of the packet are being injected as part of AWS token.
- StringToSign and Content-MD5 etc.. – more tampering prevention and obfuscation.
- Signature: One way hash encryption of the whole amalgam above.
More thoughts:
- The token will contain a time stamp so it will expiry on inactivity.
- The token could optionally contain business sensitive data too. userID or any businessID’s.
Lastly, depending on requirements, you may want to consider using OAuth too.
Have a crafty and secure fun!
Great news. HTTP4e adds BASIC and DIGEST Authentication support. Bellow is the Configuration Dialog on Ubuntu:
Another exciting news for HTTP4e. Fonts on Linux and Mac OS X have been finally fixed.
HTTP4e on Mac OS X Leopard:
HTTP4e on Ubuntu:
A good news for the Bulgarian community. HTTP4e supports unicode which means all those young kids can start start phishing on … drum rolls … unicode 
Joke aside, have a look on the screenshots. Chinese and Cyrillic characters right on your favorite RESTful client. Cutie, eh?
Many people are complaining about HTTP4e don’t supporting Authentication. Yet, a bit of knowledge about Basic Authentication would help them realize that performing authenticated request is nothing more than passing an additional “authentication” header.
Opening Wikipedia at http://en.wikipedia.org/wiki/Basic_access_authentication
the following sequence of packet negotiation is being passed across the wire:
Request One:
GET /private/index.html HTTP/1.0 Host: localhost
HTTP/1.0 401 Authorization Required Server: HTTPd/1.0 Date: Sat, 27 Nov 2004 10:18:15 GMT WWW-Authenticate: Basic realm="Secure Area" Content-Type: text/html Content-Length: 311 blah blah ...
Request Two:
GET /private/index.html HTTP/1.0 Host: localhost Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
HTTP/1.0 200 OK Server: HTTPd/1.0 Date: Sat, 27 Nov 2004 10:19:07 GMT Content-Type: text/html Content-Length: 10476
What does this tell us? Request one is trying to retrieve a resource on server localhost. Receiving a response back with 401 Authorization Required, the client makes second attempt (Request Two) passing this time some magic header and the server seems to like it by giving back 200 OK. The magic header is “Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==”. The formula of the encoded string is nothing else, but Basic64 encoded text, so any online Base64 tool will decode the text to its human readable “username:password” value.
Back to the original post. How does this relate to HTTP4e? Well the tool doesn’t have the GUI utility to plug this header to the request sending. Yet, this doesn’t mean it doesn’t support Base Authentication. All you need to do is pass that magic header into your requests. So if you construct an HTTP call against server www.abc.com protected by Base authentication with username:password, pass this additional header to to that call.
Authorization: Basic <the Base64 encoded string "username:password">
Thanks for reading this far.
Many of you probably sill think that the META headers are the solution for No-Caching.
<meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Expires" content="-1" /> <meta http-equiv="Cache-Control" content="no-cache" />
I came across this excellent tutorial by Mark Nottingham http://www.mnot.net/cache_docs/. It explains why ”Pragma: no-cache” doesn’t work and why you should use the Cache Control HTTP Headers instead.
Last-Modified If-Modified-Since ETag If-None-Match Cache-Control: max-age=3600, must-revalidate
The HTTP4e hidden features list is published. The tool has so many hidden features, such as auto complete, panel expand, proxy configuration, etc. Yet folks are totally unaware of them. My bad. It’s interesting how publishing a single list could take a year!
The purpose of this post is to demonstrate interecepting GWT RPC native calls. This would help GWT developers better understand the low level packet communications, as well as help with debugging and and tampering the requests.
The post is based on the GWT 1.6 StockWatcher example. Tools used are:
Assuming you successfully downloaded and installed the Google StockWatcher example and set the project into your Eclipse IDE, run the given StockWatcher.launch task.
And the regular hosted mode shows up.
Clicking SEND makes an AJAX call with a response popup being returned back.
So the question is, what kind of call is that GWT “Remote Procedure Call”? A regular XMLHttpRequest call, JSON, XML, binary? To anylize it, we need to intercept the http packets. So, let’s compile the project using the project ANT build.xml task and a fully compiled web project shows up
/StockWatcher
/war
__html's and css's__
/stockwatcher
__compiled JavaScripts's__
/WEB-INF
__servlets, libs, classes, etc..__
Deploy the web project to your favourite WEB container. I am lazy and I simply moved the /StockWatcher/war directory to /tomcat/webapps. Alternatively I could have created a WAR, etc.. That’s not important, the point is you need to have the StockWatcher example running on a web server. To test the app, open a web browser and run the URL http://localhost:8080/<the-name-you-gave-for-this-webapp>/
You should see the page bellow:
So far so good. What we want to accomplish is once again, intercept and tamper that native GWT Remote Procedure Call.
Intercepting GWT RPC call
Open Fiddler and attach it to your browser. Run the application again from your browser and Fiddler should list the GET HTTP calls being transmitted to server:
Click the [Send] button again and observe the HTTP call in Fiddler.
Having the RPC call in Fiddler, we want to dissect it, so let’s switch to HTTP4E, so we can replay it. Copy all the headers from Fiddler to Http4e/Headers Editor. Same for the packet body, copy it to Http4e/Body editor. Hit Run.
And Voila. Running the call from Eclipse HTTP client produced exactly the same response we received while intercepting it with Fiddler.
Few things to notice here:
- The response received is gibberish as it is gzipped.
- There are tons of headers being transmitted, but are they really needed?
- The content-type being send is: Content-Type: text/x-gwt-rpc; charset=utf-8, And this is the most important GWT header. Without it GWT Servlet is not happy and errors out.
- Did you notice the Accept-Encoding: gzip. header? Yes, that’s the one that tells the server we are cool with gzip and GWT server gets back with gzip payload. Removing it stripes out the GWT to a bare regular text
Tampering GWT RPC call
Let’s cut the weed headers and leave just the required content-type. What we are aiming is making a successful tampered GWT RPC call.
Eureka! The call returned 200 Success along with the unzipped RPC content. What’s interesting is that the native RPC response format is actually … drum rolls… JSON !!
There is the //OK or //EX prefix to indicate that response was Success //OK, or Error //EX. Other than that, it’s a well formatted JSON.
What we want to do next is, tamperig the request and pretend we are a JavaScript native GWT client. The idea is to proove that we can fool the native RPC Servlet. So, modify the RPC argument String “GWT User” to “TAMPERED-REQUEST” and run it again.
RPC responds with 200 //OK !
And that’s all folks. For you, I leave the exercise of:
- exporting the HTTP call to Java (HTTP4E/Export-to-Java)
- make an infinite loop
- and use that expertise when bringing your favourite russian server down with DoS attack
Cheers
I am glad to announce that HTTP4E reached version 1.4.3. So what is in the new release?
Version 1.4.x changes:
- Introducing JSON View
- SSL support! Finally I sneaked some time from the kids to implement it. That is said the prevois SSL prefernce window has been removed as it is no longer needed.
- Fixing Mac Fonts. Are you using http4e from Mac OS? Well. Now is the time to check out the plugin.
- Minor bug fixes such as Java one click code generation
- Persisting HTTP Body view. For some reason HTTP4e was persisting everything HTTP Headers, HTTP Parameters, Response, Request panel, etcc., but the Body. Anyhow, this release fix this one too.
Enjoy it and don’t forget to give a feedback
Please rate the plugin on Eclipse forum too.
http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-1093.html
