I have a client application that is communicating with an ASP.NET web service using cookie-based authentication. (the clients call a login method which sets a persistent cookie that is then re-used across requests within the logon session).
This has been working fine for some time, but I have started getting error reports from a few machines used by a new client that seem to indicate that the cookie has not been successfully roundtripped. (Login requests are all successful, but all subsequent requests fail with a 302-redirect to the logon resource)
I am using a CookieContainer which I manually attach to each HttpWebRequest I am using to ensure that the cookies are preserved across every request.
Is it possible that there is some "security" software on these machines that is intercepting/blocking the cookie transmission? (I am using SSL). If so, is there anything that can be done to tell what is getting in the way?
It's highly unlike that security software can even see inside your packet if you're using SSL. SSL data should be encrypted even before they get into packet form; generally they are encrypted even before using the send() to the socket. Unless you have some awesome security software that has broken SSL encryption and can look inside the packet, this shouldn't be possible.
Are the same machines failing every time? Or are some machines failing randomly at times, and others failing at other times? If it's the latter, maybe there's something going on on the server, not the clients.
Related
I am not sure of what it is called, but what happens is that my POST method request can be captured by a tool like (burp suite) and change the POST to GET.
Afterwards the process would still continue, but now it shows the parameters and its value in the URL.
How do I defend against this kind of attack?
The website is on ASP.NET C#.
Burp suite is a "man in the middle" (MITM) proxy with injection/manipulation capability. If your site is on http (not https), then yes: you are completely at the mercy of every intermediary that the traffic passes through. Change your site immediately to use https with a valid certificate.
For this to work on https, you need to deliberately break your machine, by installing a dodgy root certificate authority that will issue fake certificates for the sites it wants to MITM. This only passes your browser's security system because you broke your machine.
An attack that depends on the client already having been compromised is not an interesting attack from a server perspective. All you can reasonably do is protect intact clients. By using https and disabling http (non-TLS). You can do things like reject GET if you're expecting POST - but this doesn't change that the GET will have happened. But note:
the MITM proxy can already read the POST variables without needing to change them to GET: it is in complete control of the data
other intermediaries between the MITM proxy and your server cannot read the data regardless of whether it is GET or POST, as long as it is https (which is why you need to disable http, not just enable https)
the only thing you're changing with GET vs POST here is what appears in your own server logs... and it doesn't matter how you respond to the request at that point: it has already been logged, even if you return 404 or 500 or whatever
I'm creating a crawler which uses several IP Proxies. Whenever I tried to crawl the website without proxy, I'm able to get the html source, but when I tried to enable the ip proxy, it always fail and throws an exceptions (The remote server returned an error: (403) Forbidden.)
Upon looking at the fiddler, it seems the website stores cookies upon visit. But if the proxy is enabled, it fails at get response part.
I don't understand why the cookies was not set using a proxy? Is it the proxy server settings for cookies that cause it? or I can do something about it while still enabling proxy?
I'm using C# by the way, but the question doesn't seems language dependent.
Another thing to consider is that you set a cookie from the ip address of the non proxied machine (which worked), then when you sent another request with the same cookie from another ip address which might have gotten you blocked.
Some network level software looks at stuff like this which might have flagged you as a malicious crawler or annonymous tor browser.
Recently, We developed an application that we want it's users to pay for a monthly subscription in order to use it. So the first thing that came to our minds how to implement a secure way for our application to check for the User validity and those ideas came up
Using WebClient to enter to our website and Login using the user
provided credentials : However, this might be vulnerable to MITM
attack.
Using the first approach but using SSL certificate (to make sure
that we are connecting to our server and not the attackers') :
However, Fiddler can easily do a MITM attack and decrypt the SSL
communication, which will result in the same vulnerability as the
first approach.
Due to the internet's lack of documentation of what we need, we had to ask here for someone to explain how could we make sure that:
Our application only connects to our server and not any fake hosted
server (by the attacker).
The communication is secure. Not altered or edited some how in order to
grand unfair access to our application. (by sending a fake response
to the app or editing the original response before the application receives it).
Note: we totally understand that the attacker may just deobfuscate the application and do whatever he want to it. So we are planning to get a goodobfuscatorin order to at least make it harder for the attacker to do so.
You can use SSL Certificate Pinning.
Set the ServerCertificateValidationCallback to only accept your certificate's public key, or one of its signers. (this means you can never change certificates)
This will completely prevent SSL MITM (which works by using a different certificate and making the computer trust it).
Of course, it doesn't prevent attackers from cracking open your app and bypassing the check altogether, especially if you store local state.
I have a client server application. My server is in PHP, Mysql and Apache and client is developed using C# windows Form. I have SOAP WSDL webservice for client server communication.
Recently I found a problem, when my client sends the request, response comes after very long time (like 3/4 mins to some hrs.), and sometimes I never gets response. I have checked all the timeout value in client (httpwebrequest timeout, readwritetimeout) as well as server(timeout, keepalivetimeout) side, the max value I have is 5mins (for httpwebrequest readwritetimeout). So can anybody tell what would be the problem? Why it is taking hours to get response or not geting any response?
In my experience, problems like these come with the web-service connection being blocked by a firewall, or a wonky proxy in the way. Check that this is not the issue.
You should first begin be locating the problem by narrowing down the options. Have you tried calling the web service on the server locally, see if you get the same problem - if you don't then it is with high likeliness certainly a connection problem.
To also rule out the client having problems, try using something like http://www.soapui.org/ instead to call your server web service.
Where are you calling the server from? Are you sure the device you call it from is not being IP-blocked, and are you sure your web service is able to access its database from where it is being run.
Does the MySQL user defined for your server API to use have access from the IP of the server. MySQL users are often blocked by IP as well.
If you're running it all locally, are you sure your IIS Express settings/virtual folders are not jumbled up and the URLs are resolving wrong. Try creating the virtual folder again to rule out this. Even when running locally, remember to check that the MySQL user has access from your local IP.
Here's a few things I usually check when I have issues like yours.
I am about to start on a project that will be running as a windows service listening for incoming connections and doing some things locally then sending a reply message. I understand the basic concepts with sockets and communicating over the network, however the things the service are doing could very easily abused. I would like to authenticate the person connecting, preferably against the windows local users on the machine the service is running, to see if they have windows administrative/power user rights.
I know how to do it check the rights once I have their information but I know sending the user name and password to the application over the network in the clear is a no no. I was thinking of just encrypting the password with some secret key but I know "trying to be clever" is the worst possible thing you can do in cryptography so I wanted to know what is the "correct" way to handle this situation.
My second idea was just create a shared self signed certificate between the client and the server and just use TLS for the entire connection.
I may as well post what I was thinking of doing, if it is the right thing to do say so in the comments.
Both the client and server will have a PSK at run-time the server will send a random number to the client. the client will encrypt the credentials with the PSK and the random number as the IV. It will send back the encrypted blob plus whatever commands it needs done.
I am not concerned about replay or mitm attacks. I just want to authenticate the user and not have peoples passwords blasted all over the network.
Scott,
this may be a bit overkill and a bit off topic, but have you considered using a web service interface to serve your clients (instead of using raw sockets)?
ASP .Net web service interfaces are easy to implement, and in the end, you'll end up with a very well defined interface. They also have support for authentication and secure communication.
ASP .Net Web Service Tutorial
HTTP Security and ASP.NET Web Services