I'm building out a simple C# application that integrates with a SOAP web service. I add the service reference to the appropriate WSDL and everything works out fine so far.
Occasionally, the server's firewall will respond with a 503 error before the request gets a chance to hit the web service. That 503 error also contains some HTML with an ID number (which changes each time) that I want to capture.
If I catch the exception, it doesn't give me the full message - just the re-formatted basic exception that says the server is too busy.
I tried the message inspectors suggestion from this post:
Intercept SOAP messages from and to a web service at the client
...and it gives me the outbound request, but it never hits the AfterReceiveReply call, so the response isn't captured.
I've also tried subscribing to all of the channel's major events (Faulted, Opening, Opened, UnknownMessageReceived, etc), and I've tried inspecting the channel when I catch the exception, but nothing seems to work.
Any thoughts or suggestions?
Why not just run fiddler on the machine your soap client is running on and intercept and inspect the traffic that way?
Turn on WCF Tracing. In particular, Message Logging.
It seems like disabling SOAPProcessing in the .config file may be a step in this direction, but I was unable to figure out how to enable this setting via code (and I cannot use a .config file in my final application because this is a plugin and the parent app's .config file is dynamically generated each launch).
I was able to work around this somewhat. In my situation, I had separate dev and production servers. The 503s errors were happening mostly on the production server (likely due to the firewall being sensitive about a different hostname in the API requests), so I ended up with a solution that duplicated the API requests and sent them over to the production server.
(This was okay, because the production server was not configured with anything that would be affected by any API requests that made it through the firewall. The requests would just be considered invalid.)
I did this by using message inspectors to generate the last outgoing request. Then for each outgoing request, I generated a new WebBrowser control, set the proper headers (SOAPAction and all that), re-injected the security credentials (the message inspector stripped them out at runtime), and then posted the request to the production server with that WebBrowser control. The WebBrowser instance's DocumentCompleted event let me dump the result and search for the ticket ID when appropriate.
Not exactly glamorous, but it works well.
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
We are creating a web service request for IBM Maximo web services in C#.net , the issue is apart from for few web service requests we get succesful response for all other web services, but for some requests there is no response at all, but when we give request for the same using the SOAP UI, we get response.
Where would the problem be ? Any ideas?.
Many thanks ,
byfour
Any ideas?
Start debugging. First of all, of course your application contains logging, so you can see whether any exceptions occur while sending the message.
If no exceptions occor on your end, you can configure tracing to log all actions the WCF plumbing is executing, so you can see whether that part goes well. If it does, you can start debugging the network. If you see your message going over the wire, it's time to pick up the phone and call the other party and ask if they see anything happening after they receive your messages.
We have a Win32 application that connects to a third party application to send some info to it. That application has a web service that we call its methods. One of its web methods is called GetDevices and when our application is calling it, it will fail to work and I have no idea what are the details of this failure. So we should write a small diagnosis application that can create some detailed log files to know what is going, send it to them to run it and then we may know what is going on with more detail. Now do you have any ideas what is a good way to write such a diagnosis application for this debugging purpose?
If this web service is using HTTP (either SOAP or REST) you can use Fiddler to snoop the HTTP traffic and see what's happening.
When web requests are made, the request (and response from the server) will show up in Fiddler, and you can use that to determine why it's not doing what you expect.
I have a project where I have created web service proxy classes with wsdl.exe and then simply create an instance of that class (inherits System.Web.Services.Protocols.SoapHttpClientProtocol) and call the method that should send a SOAP message. I'm using Visual Studio 2008 if that matters. And I'm trying this in my development machine without access to actual web service that is located inside of customer's intranet. So, the sending will of course not succeed and I will not get any response back but all I would like to see is the exact content of SOAP messages this solution creates and tries to send. How do I see that?
Use fiddler.
Have a look at SOAPUI from eviware.com.
Its a free for personal use Java app. Among other things you can
set it up to run as a dummy test server. Just load up hte WSDL
and enter the dummy data.
In test server mode it will log your requests so you can see whats happening
inside the request message.
If you're Web service is accessed by clear text, non-SSL HTTP, you can just use a sniffer, like Wireshark, to see the data coming from and to your application. Wireshark can trace, filter and analyze wire data. I have used it do debug HTTP and other protocols many times, and it's a great tool to do this.
SOAP messages are simply XML data sent using the HTTP POST method. So you can for example install a local web server on your development machine, configure your web service to use some dummy URI on this server, and grab the network traffic with WireShark (AKA ethereal). The big advantage of this method is that it involves no coding.
Alternatively you can use an HTTP echo server that dumps its incoming traffic, like this one (found while googling "http echo server"):
You can intercept the call with tcpMon
We have an HttpHandler that deals directly with binary posts over HTTP from custom client software. The client software occasionally sends data which results in IIS 7 responding with a 400 - Bad Request. Since the "400 Bad Request" is special in that HTTP.SYS transparently handles it in kernel mode without notifying user mode of anything, no errors are raised to be handled in ASP.NET. Is it possible to catch this http 400 in ASP.NET, so that I can write specific data to the Response stream in these scenarios? A redirect to another page isn't an option as it needs to be in the current Request/Response.
If you know what is causing the 400, then you may be able to customise the behaviour of http.sys via the registry to deal with it:
http://support.microsoft.com/kb/820129
However, you should be aware that there are potential security and performance ramifications of doing this.
Another option would be to use a filtering proxy before IIS, thereby capturing the request before it goes any further.
I would instead ask them to fix the custom client software. Give them a report showing the failed requests. If you are able to, run a sniffer such as Wireshark and send them the packets if they do not believe the problem is with their software.
If your custom client causes IIS to trigger HTTP 400, it's probably flawed and is not submitting valid HTTP requests according to the standard. If you can alter the client, it would be the right thing to do. Otherwise, what you're working with is not HTTP, and IIS is designed to handle HTTP requests. Therefore, you should run a custom server for your own protocol (which is a non-standard HTTP like thing).
It's not advised to use IIS/ASP.NET to handle such a request as it might cause some weird unexpected things to happen.