ASP.NET and man-in-the-middle

Question

Does ASP.NET use a mechanism for disallowing manipulation of data between client and server?

If not, does it mean we should use SSL? What kind of attacks can SSL prevent?

If yes what is this mechanism?

Answer 1

ASP.Net uses Viewstate on the client side to retain values - which is practically unbreakable. However, any web application passes (posts) data to server via webbrowser which is passed in the chunks of packet data using TCP/IP protocol. This information can be easily monitored using some software to see what data is being transmitted (however, changing this data while being transmitted to server seems very very difficult in real time). SSL simply encrypts the data (say your user name and password you typed in the login box) before browser sends it the server; this data while being transmitted on TCP/IP channels can be monitored but it would be in encrypted format. Thus, secure.

However you can make your application secure by taking care of the points from this links:

• http://ethicalhackingaspnet.codeplex.com/
• http://msdn.microsoft.com/en-us/library/ms972969

Answer 2

No, the ASP.NET webforms and mvc frameworks do nothing to protect transport of data between client and server. The viewstate is an encrypted piece of data in webforms, but that does not mean it can't be tampered with on the way to the server or client. The short answer is to use at least 128 bit ssl using a CA signed certificate if you want to prevent man in the middle attacks.

Answer 3

To disallow data manipulation between client and server, you have to have a way for the server to detect such manipulation. For viewstates this can be enabled in asp.net by making sure the viewstates have mac and encryption enabled. Oh, and you should also set a viewstateuserkey.

For other parameters however, an attacker can manipulate the parameters. So use SSL/TLS. SSL/TLS sets up a encrypted connection between your client and server, making it impossible (unless poorly configured) for an attacker to sniff out data or manipulate the content.

Not using SSL/TLS, allows all sorts of attacks (sniffing session cookies on open wireless networks, injecting packets and manipulating the returned web page etc.)