I'm looking for details on the DEBUG HTTP verb.
It's clear to me that this is used for remote debugging - though I'm not even sure if it's for IIS or ASP.NET...
If I want to access this interface directly - i.e. not through Visual Studio, but sending these commands manually - what do I need to know? What are the commands for it?
I'm also interested in misuse cases, if you have any information on that...
Just for completeness, consolidating here the answers from what-is-the-non-standard-http-verb-debug-used-for-in-asp-net-iis: (thanks #Mark, #Jørn).
http://support.microsoft.com/kb/937523
When the client tries to automatically
attach the debugger in an ASP.NET 2.0
application, the client sends a HTTP
request that contains the DEBUG verb.
This HTTP request is used to verify
that the process of the application is
running and to select the correct
process to attach.
The DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug, but the actual debugging is done via an RPC protocol.
It uses Windows authentication, and DCOM to actually do the debugging though (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.
However, poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true">. The test can be performed with telnet, WFetch or similar, by sending a request like this:
DEBUG /foo.aspx HTTP/1.0
Accept: */ *
Host: www.example.com
Command: stop-debug
Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden.
It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway.
If you want to do remote debugging, I would suggest utilizing debug.writeline and the tool from sysinternals DebugView. This allows you to 'listen' for debug statements either on your location machine or on a remote machine, provided you have the necessary access.
I cannot directly answer the part about DEBUG http as I am unfamiliar with it.
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
This will probably be an environmental issue but I'm stumped as where to start.
I'm attempting to call a a webservice on an external server in an asp.net web app while debugging in VS2008. The exact same code/project works on one machine calling the server but on another machine (my new one) it fails with the 400 Bad request (data is invalid) error.
Both machines are running Windows 7. What should I be looking for as differences in the two machines that could be contributing to this problem?
Edit Deleting the webreference in the project and re-creating the webreference had no effect
Update
I went to use Fidler2 to inpect the request and response which resulted in the error going away. Things are beginning to point to an internet proxy issue.
It's an Internet Proxy issue. The suspect machine had be configured to manually use a proxy server. Turning this off: Control Panel -> Internet Options -> Connections Tab -> Lan Settings Button, and enabling "Automatically detect settings" has fixed the problem.
I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.
I'm experiencing some really odd timeout issues when running a ASP.NET 2.0 project on Cassini on localhost, and I don't have enough data to get a clue of what's going on.
Is there a way to monitor localhost traffic to Cassini, either using some specific development tool or a general-purpose monitoring app such as fiddler?
Just to pre-empt some answers I'm already aware of:
Normally I can use the well-known dot-hack for using fiddler to monitor localhost traffic, but with Cassini I get the following error message in the browser:
[Fiddler] Connection to localhost. failed. Exception Text: No connection could be made because the target machine actively refused it ::1:3213
Fiddler also listens to localhost on http://ipv4.fiddler:port, and I can intercept the traffic. But when I do this the timeout issues don't occur!
Any other tools or fiddler workarounds welcome! Thanks!
Edit: Oops. This question had already been asked... Twice.. Didn't come up on search or suggestions. The solution found in the second thread is to use the dot-hack with ip-address (http://127.0.0.1.:port/ instead of "localhost". This question may be closed.
While fiddler ignores requests to localhost, it listens to 127.0.0.1. (note the trailing dot):
So this won't work:
http://localhost:1234/
But this will:
http://127.0.0.1.:1234/
You're generally better off using http://ipv4.fiddler as it makes it more explicit what you're trying to do.
CassiniDev is an open source project that was developed to fill in all the blanks left by WebDev.WebServer/Cassini.
You will find this issue handled as well as many others.
It works well as a stand-alone server, as an in-process server suitable for testing and embedding and, most notably, as a direct replacement for the Visual Studio 2008/2010 dev servers.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=cassinidev&DownloadId=123367
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=cassinidev&DownloadId=123366
I need to see the actual requests being made from a asp page to the webservice(which calls another webservice). All these requests happen on the same local box. I ran the "proxycfg -p http=127.0.0.1:8888;https=127.0.0.1:8888" on the command prompt based on
http://www.fiddler2.com/fiddler/help/hookup.asp#Q-WinHTTP: How can I configure a WinHTTP application to use Fiddler?
I now see the webservice wsdl requests in Fiddler but not the actual requests. Would someone know why??
If your WS calls are going to your local machine, make sure the URLs they are using are "localhost." instead of "localhost" - notice the dot in the first instance. Otherwise fiddler never gets a chance to pick up the request.