CODEWITHSUNDEEP
javaajaxsecuritygwtssl
azec.me
azec.me

Reputation: 5078

GWT with SSL security

I was wondering what are the security flaws (if any) of using GWT with SSL (actually TLS configured on JBoss web-app server). I discussed this with friend of mine, and he says that even if I enable HTTPS, some malicious user would be able to intercept my .js and change code and get authenticated on the server. We assumed that besides SSL we never send plain-text password on wire (we hash it first). Is this really possible?

The other thing I would like to know is - how does Javascript code (generated by GWT) fire RPC calls? We used Wireshark to sniff requests and responses from client to SSL-enabled web server, and there are none of the RPC packages going around. All we see are these TLS protocol packets, we can easily identify them by using filter on source and destination IP addresses of client and web server.

Upvotes: 3

Views: 4174

Answers (2)

blackhat016
blackhat016

Reputation: 1

To be completely sure in your SSL/TLS configuration I suggest you use some external tool. So far most accurate for me was SSL/TLS Server Test. There you can see how your configuration complies with PCI DSS requirements, or guidelines from HIPAA and NIST, which are industry standards for securing SSL/TLS.

Upvotes: 0

Chris Lercher
Chris Lercher

Reputation: 37778

If you also send your .html and .js files via HTTPS, then - generally speaking - no one will be able to manipulate them during transfer. Of course, there are some practical questions:

  • Does the TLS implementation have any bugs?
  • Are there flaws in the TLS protocol?
  • Is the client's browser or computer compromised?
  • Is the server compromised?
  • ...

Let's assume, that's not the case. But then there's your statement:

We assumed that besides SSL we never send plain-text password on wire (we hash it first).

So you don't send everything via SSL? Well, the things you don't send via SSL can be stolen and manipulated during transfer. I assume, what your friend means is, that the hashed password can be stolen! Even though the attacker may not be able to reconstruct the plaintext password, he can simply use the hashed password, if your server accepts the hashed password.

Also see my answer to GWT/Javascript client side password encryption.

About your second question:

We used Wireshark to sniff requests and responses from client to SSL-enabled web server, and there are none of the RPC packages going arround. All we see are these TLS protocol packets...

Well, I really hope so! Your RPC calls are the encrypted payload of these packets. You can use Wireshark's SSL dissector to decipher the package, if you can provide the private key to Wireshark (be very careful when using with production keys!)

Upvotes: 4

Related Questions