i don't want to fiddler capturing my web application activity . i want to make my application more secure like banking site .while using internet banking site the fiddler cannot able to capturing the details. how can i make it by using C#.net in asp.net web application.
Fiddler can also capture HTTPS traffic if the user accepts the root authority certificate it installs when you enable 'Decrypt HTTPS traffic' in Fiddler Options.
Fiddler acts as a standard HTTP proxy. There is no way you can prevent Fiddler from intercepting and decrypting the traffic if the user chooses so, although Certificate Pinning can make things a bit harder on the Fiddler user.
You could of course use some kind of symmetric encryption to encrypt the payload of your requests, but you'd need to store the key somewhere on the client, making it vulnerable to attackers. See here for more info on JavaScript encryption.
Request.Proxy = New WebProxy()
This blocks the fiddler to set itself as a proxy.
Related
Is there a way to configure IIS or mark up my code so that the client (any major modern browser) will always include Kerberos information in the response without having to make any modifications to the client itself?
In this specific server method, I'm using ASP.NET impersonation with delegation enabled in AD and it would seem that from firefox and a few other clients, Kerberos data is not being passed from the client to the server.
My application only has Windows Authentication enabled, but how can I force the requests to pass Kerberos information along?
If it helps, I'm using jquery's ajax to GET or POST my requests to the server.
As long as your server is returning "WWW-Authenticate" headers that indicate it accepts Kerberos authentication ("Negotiate"), the client should automatically supply the necessary credentials. Make sure that Negotiate is listed as a possible provider for Windows Authentication in the Authentication configuration of your application. You'll probably want to disable NTLM in that list.
You can tell if the client is sending Kerberos tickets if you look at the HTTP headers. It should have something like "Authorization: Negotiate YIIN..."; the first few base64 characters of the payload let you distinguish between Kerberos and NTLM.
I already have an existing LAMP application. I am going to integrate a 3rd part API which uses C#, so I'm planning to create a Web API for them to be connected. No other website will connect to the web API other than the LAMP app. How do I make a secure connection from my LAMP app to the web API? Thanks.
If it is just API calls and nothing dealing with interfaces you can use Encrypted WebSockets or create your Authorization headers... which could be a bit of work and would only work between the those two applications.
The most secure way to lock them up is a combination of a secure HTTP request (HTTPS) coupled with a Client Certificate.
All of these things are quite a tall order; you're best bet is to just get/create a half-way decent SSL certificate and use BASIC authentication. Your authorization headers will be encrypted. Even a self-signed certificate would work; make sure to research on how to make a self-signed certificate the most secure it can be. Also your LAMP server will likely make use of cURL to send the requests to the C# server, you'll want to make use of the curl -k option if you're going to be using a self-signed cert.
I am using u web service developed in wcf. And it has made secured using digital certificate.
The data decrypted at client side itself.
I found that it does "man-in-the-middle" approach to do the same.
But I could not get a explanation about how to block HTTPS analyser to decrypt the data.
Can anyone help me with some code or link?
If you want to prevent a man-in-the-middle attack, you need to ensure that the SSL certificate is trustworthy. If the https traffic can be intercepted then either the SSL certificate isn't from a trusted source, or the analyser has access to the private key.
If you want to learn more and see how it works, have a look at this post about Fiddler. Fiddler acts as web proxy and can be configured to decrypt https using man-in-the-middle.
Why make use of HTTPS when Fiddler can decrypt it
I asked a question here a while back on how to hide my http request calls and make them more secure in my application. I did not want people to use fiddler 2 to see the call and set up an auto responder. Everyone told me to go SSL and calls will be hidden and information kept safe.
I bought and installed an SSL Certificate and got everything set up. I booted up fiddler 2 and ran a test application that connect to an https web service as well as connected to an https php script.
Fiddler 2 was able to not only detect both requests, but decrypt them as well! I was able to see all information going back and fourth, which brings me to my question.
What is the point of having SSL if it made zero difference to security. With or without SSL I can see all information going back and fourth and STILL set up an auto responder.
Is there something in .NET I am missing to better hide my calls going over SSL?
EDIT
I am adding a new part to this question due to some of the responses I have received. What if an app connects to a web service to login. The app sends the web service a username and a password. The web service then sends data back to the app saying good login data or bad. Even if going over SSL the person using fiddler 2 could just set up an auto responder and the application is then "cracked". I understand how it could be useful to see the data in debugging, but my question is what exactly should one do to make sure the SSL is connecting to the one it was requesting. Basically saying there cannot be a middle man.
This is covered here: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Essentially, you manually trust whatever certificate Fiddler provides, the same will be true if you manually accept certificate from random person that does not match domain name.
EDIT:
There are ways to prevent Fiddler/man-in-the-middle attack - i.e. in custom application, using SSL, one can require particular certificates to be used for communication. In case of browsers, they have UI to notify user of certificate mismatch, but eventually allow such communication.
As a publicly available sample for explicit certificates, you can try to use Azure services (i.e. with PowerShell tools for Azure) and sniff traffic with Fiddler. It fails due to explicit cert requirement.
You could set up your web-service to require a Client-side certification for SSL authentication, as well as the server side. This way Fiddler wouldn't be able to connect to your service. Only your application, which has the required certificate would be able to connect.
Of course, then you have the problem of how to protect the certificate within the app, but you've got that problem now with your username & password, anyway. Someone who really wants to crack your app could have a go with Reflector, or even do a memory search for the private key associated with the client-side cert.
There's no real way to make this 100% bullet proof. It's the same problem the movie industry has with securing DVD content. If you've got software capable of decrypting the DVD and playing back the content, then someone can do a memory dump while that software is in action and find the decryption key.
The point of SSL/TLS in general is so that the occasional eavesdropper with Wireshark isn't able to see your payloads. Fiddler/Burp means that you interacted with the system. Yes, it is a very simple interaction, but it does require (one) of the systems to be compromised.
If you want to enhance the security by rendering these MITM programs useless at such a basic level, you would require client certificate authentication (2-way SSL) and pin both the server and client certificates (e.g. require that only the particular certificate is valid for the comms). You would also encrypt the payloads transferred on the wire with the public keys of each party, and ensure that the private keys only reside on the systems they belong to. This way even if one party (Bob) is compromised the attacker can only see what is sent to Bob, and not what Bob sent to Alice.
You would then take the encrypted payloads and sign the data with a verifiable certificate to ensure the data has not been tampered with (there is a lot of debate on whether to encrypt first or sign first, btw).
On top of that, you can hash the signature using several passes of something like sha2 to ensure the signature is 'as-sent' (although this is largely an obscure step).
This would get you about as far in the security way as achievable reasonably when you do not control (one) of the communicating systems.
As others mentioned, if an attacker controls the system, they control the RAM and can modify all method calls in memory.
I'm currently developing an application in C# for Windows Phone against an HTTPS web service. An example of the endpoint that I'm accessing is as follows: https://apitest.letsfreckle.com/api/projects.json?token=lx3gi6pxdjtjn57afp8c2bv1me7g89j
When I inspect the network traffic using Fiddler with the "Decrypt HTTPS traffic" option enabled I get a "NotFound" exception in my code. If I disable the "Decrypt HTTPS traffic" option in Fiddler, then I get the response that I would expect in my code.
In Fiddler, I see the HTTP CONNECT request with a result of 200, but nothing else.
I'm using Fiddler v2.3.7.4 beta on 64-bit Windows 7 with no filters. I have no proxy servers configured and the problem persists if I disable my anti-virus protection (Microsoft Security Essentials). I have tried removing the interception certificates and the root and site-specific certificates are correctly re-created.
I appreciate that this scenario works perfectly well for the many Fiddler users out there, but would be grateful if you could shed any light on why it's not working for me.
UPDATE: I can hit the endpoint and get a response just fine using a browser and when not decrypting HTTPS traffic through Fiddler and when Fiddler is not involved.
You can install the certificate on the emulator, I use an HTTPS endopoint in my app too and I can decrypt the traffic.
You need to visit with IE Mobile this URL: http://yourmachine:8888/ and click on the link "install the root certificate", after you should be able to see the traffic beyond the handshake (CONNECT)
You need to start Fiddler bedore the emulator I think.