I've created an ASP.NET WebService that is to be consumed using ASP.NET Ajax. The WebService is located on the same box and same web application that it is to be used by, so I do not want to allow remote access to this webservice, but have it only respond to requests from localhost.
The Web.Config DOES NOT have a configuration section and therfore does not have httpPost and httpGet turned on. This is fine. However, if I navigate directly to the WebService URL from a remote machine, it still loads and shows me a list of methods. Clicking on the method does give me a message stating that the testing form is not available to remote machines (as intended), but it does list information on how to issue a Soap Request and handle a Soap Response.
Additionally, I believe I'm being scraped by a bot of some sort of just a curious user, because I'm now getting error message in my log such as this...
System.InvalidOperationException: Request format is unrecognized for URL
unexpectedly ending in '/ValidateUsername'.
This happens if you try to issue a GET request (by manipulating the query string) against the service remotely. I'm glad that it's not handling the request as I don't want remote users access to this service, but I would prefer it not throw an error.
How can I lock down the webservice so that it is not available to remote machine, but still available to the local machine as a ScriptService consumably by ASP.NET Ajax?
UPDATE:
Okay, here is workable example of what is happening.
WebSite: http://so.weirdwes.dyndns.org/default.aspx
WebService: http://so.weirdwes.dyndns.org/services/services.asmx
Web.Config:
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
</protocols>
</webServices>
The website is consuming the WebService using a ScriptManager tag and ScriptReference. You'll note if you click the button, the web service is called and everything works, even though Post and Get have been removed. This is fine as this is how we want it to work. The issue is this....
http://so.weirdwes.dyndns.org/services/services.asmx/GetRemoteAddr
Server Error in '/' Application.
--------------------------------------------------------------------------------
Request format is unrecognized for URL unexpectedly ending in '/GetRemoteAddr'.
A bot or something is scraping this URL and it's generating errors that we're get notified of. I want to supress this error or block it entirely. If I alter the Web.Config and add the Get and Post protocols back in, this error goes away - but then it allows access to the web service remotely using Get which we don't want.
I am kinda confused here.
Is this going to be called by the browser? if it will be, then you should allow remote access.
Test against the ip address
Request.ServerVariables ["REMOTE_ADDR"]
IIS lets you white/black list IP groups in its configuration. Use that to lock it down to localhost. You can also configure your firewall to prevent anyone from hitting that port from outside.
Related
I'm trying to appease a PCI scan failure we recently had done, in which it states:
Microsoft ASP.NET MS-DOS Device Name DoS
Synopsis :
A framework used by the remote web server has a denial of service vulnerability.
Impact:
The web server running on the remote host appears to be using Microsoft
ASP.NET, and may be affected by a denial of service vulnerability. Requesting a URL
containing an MS-DOS device name can cause the web server to become
temporarily unresponsive.
In a nutshell, we visit a URL on our app such as /AUX/.aspx we get a 500 error.
I'm using RequestFiltering to filter these requests out, and return 404's instead, without the server trying to process the request.
An excerpt of my web.config is below:
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence="/AUX/.aspx" />
</denyUrlSequences>
</requestFiltering>
</security>
</system.webServer>
However, this isn't working, it's still returning a 500.
I would expect it to return a 404.
If I add the following catch-all url to the denyUrlSequences then the whole site produces the expected 404.
<add sequence="/" />
It's worth mentioning the application in question is an MVC app running on IIS 7.5 (Windows 2008 R2)
Just had to solve this problem.
My solution was to disable .Net Error Pages and enable IIS Error Pages.
When you move the custom error handling from the higher .Net level to the lower IIS level the HTTP response code changes from 500 to 404.
PCI Test Passed :-)
I struggled with this for quite some time myself. I think the 500 response code is correct for MS-DOS names in the URL, and you do not need to add anything to request filtering.
You'll notice that you will get a 500 error if you use any of the MS-DOS names (https://support.microsoft.com/en-us/kb/74496) without doing anything to your configuration. However, if you add a RequestFiltering denySequence for something else, like "foo", then you will see the 404.5 error when browsing to /foo.
If you add relaxedUrlToFileSystemMapping="true" to the httpRuntime element along with your request filtering denySequence entries, then you will get the 404.5 for MS-DOS names.
But disabling the default asp.net configuration just so you can get something other then a 500 response for a URL with MS-DOS name is a rediculous request from a PCI compliance check.
I moved from IIS 6 on windows server 2003.
I can browse to the .svc files. I get a nice standard "This is a Windows© Communication Foundation service" page if I go to http://example.com/Service.svc in a browser.
But I can't browse to any of the methods - I get a 404 error if I go to http://example.com/Service.svc/Method?parameter=xyz in a browser.
Has anyone seen anything like this? Any ideas or suggestions?
I thought I might have a similar problem to this question: WCF on IIS8; *.svc handler mapping doesn't work
But the symptoms are different (looks like they can't see .svc files at all) and none of the solutions work (I have Http Activation for WCF features installed, etc).
OK, I gave up and paid Microsoft $250 for support. With the tech's help, we found the solution, and last night confirmed that it was definitely the solution for all our servers: We disabled SSL altogether for WCF services in the web.config:
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding>
<security mode="Transport" />
The "Transport" refers to Transport Layer Security (TLS is the new SSL) so HTTPS. Changed that to:
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding>
<security mode="None" />
Turns out WCF is extremely sensitive to whether you are using HTTP or HTTPS, and if you are using the wrong one you get no helpful errors, just 404.
In my case, both old and new servers were configured to use HTTPS at all times for security. But on the new servers, the SSL (TLS) encryption terminated on the load balancer. In that case encryption only happened between the user's browser and our load balancer, and the traffic between our load balancer and the web servers was unencrypted HTTP.
So the service was listening on HTTPS, and when the request came on HTTP, it just completely ignored it.
(All the other talk about similar issues online focused on uninstalling and reinstalling IIS and ASP.NET and WCF and HTTP Activation and such, so I hope this helps someone. I recommend MS Support if you have a question on the MS stack that SO can't answer in time. It was certainly much cheaper than wasting a few more hours trying to fix it alone).
Please check if your IIS has svc handler added.
WCF services don’t run on IIS 8 with the default configuration, because the webserver doesn’t know, how to handle incoming requests targeting .svc files. You can teach it in two steps:
Add a new MIME type:
Extension: .svc
MIME type: application/octet-stream
Add a new Managed HTTP Handler:
Request path: *.svc
Type: System.ServiceModel.Activation.HttpHandler
Name: svc-Integrated
Refresh your website/web application
References:
http://gyorgybalassy.wordpress.com/2012/09/24/publishing-a-wcf-service-on-iis8/
http://proq.blogspot.hk/2012/09/wcf-on-iis-and-windows-8.html
http://forums.iis.net/t/1200413.aspx?+svc+missing+can+t+find+Module+to+load+within+Handler+Mapping+IIS+8+0
Just wanted to provide a collection of suggestions in case you haven't tried one of these:
Any chance the [OperationContract] is missing for the intended method?
Do you have any url rewrites configured in the web.config that could be redirecting the method calls, such as an HTTP/S redirect or some route configuration?
Enable Failed Request Tracking in your IIS to see what sub-type of 404 error you are getting? 404.13? something else? It is likely not because something isn't found, but some other error in the request.
Additional Sources:
http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
WCF service returning 404 on method reqests
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7d69a209-489e-486c-81f4-a660c539ae49/wcfiis-7-returns-404-but-only-for-some-method-arguments?forum=wcf
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7d69a209-489e-486c-81f4-a660c539ae49/wcfiis-7-returns-404-but-only-for-some-method-arguments?forum=wcf
You can enable tracing/logging in wcf service , so that you can check actual cause of error, if there is mismatch in param or any other thing , directly from error logs.
Refer this to enable tracing, it is just simple config setup - http://msdn.microsoft.com/en-us/library/ms733025(v=vs.110).aspx or How to turn on WCF tracing?
...
Other suggestions:
In ServiceContract, for required method, you have used required attributes. So lets say, Service.svc has servicecontractor defined in IService.cs, and you are concerned about Method. Then Method should be declared like this.
[OperationContract]
[WebGet(UriTemplate = "Method?parameter={value}")]
string AnyMethodName(string value);
Here i have used string as both input and output param type, you can use required type here.
Apart from this, you need to have required web.config to have service,binding,endpoint etc. configured properly. Refer - http://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx
So that if you host it in http://www.example.com, then you can execute REST based Get request using http://www.example.com/Service.svc/Method?parameter=XYZ.
More info - http://www.c-sharpcorner.com/UploadFile/b1df45/rest-based-api-using-wcf-services/
Also, as suggested above, there might be some URL rewriting setup, that you have check and fix. or try with https version of URL directly. Or if there is some proxy server that is blocking, has to be checked.
If there is request filtering setup, then check if GET request is blocked there.
Or if at all possible, re-register IIS using aspnet_regiis.exe -iru.
Hope it will help to somebody though its late to reply to this post.
I got the same problem and spent hours and hours to find the solution. Finally ended up changing
Luckily I got the answer changing RouteConfig.Cs file as follows From
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
To
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");
as long as you should place your .svc file in root of your application.
That was my own question asked on this link
WCF Service throws Http404 on any request except .svc
I have an ASP.NET asmx web service running on IIS.
A client is trying to consume the service, and I can see (after a rebuild) that the Global.asax Application_Start is getting hit from his attempt... but the specific function is not getting hit.
This link
Getting RAW Soap Data from a Web Reference Client running in ASP.net gives a "solution" for what I'm trying to do, but it didn't work.
I placed the above link's suggestion in my web.config, but no log file is generated even when I successfully call the service myself.
If you're looking to trap request/response on the client side, you can connect to ASMX webservices using WCF-style generated proxies just by using a "Service Reference" rather than a "Web Reference", then follow the WCF tracing you linked to for raw data, as well as using System.ServiceModel.MessageLogging for SOAP-specific stuff. Keep in mind that:
the maxdatasize attribute for System.Net will truncate the data logged, so pick a bigger number if your request/responses are larger. Use maxSizeOfMessageToLog with System.ServiceModel.MessageLogging.
remove the raw ascii/hex and only show the xml with tracemode="protocolonly" in the <source name="System.Net"> element
But if you want to trap requests on the server side (i.e. from within your ASMX webservice) you can try the suggestion here, which is to just read the data out of the request stream in Application_BeginRequest and probably also the response stream in Application_EndRequest.
I've got a bit of an odd situation that recently came up in a security scan and I'm having trouble explaining it. In short, the following URL always returns HTTP 400 and a YSOD:
http://www.mypal4me.com/C:badfile
This site is ASP.NET 4 and is hosted on MaximumASP under IIS7.5. This site is configured with custom errors turned ON and a default redirect page. This is evidenced by causing request validation to throw you off to the error page: http://www.mypal4me.com/?%3Cscript%3E
The only way we've found to send this request off to the custom error page is to add an <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> entry under system.webServer.httpErrors in the web.config (obviously this hasn't been done on the site above but has on other MaximumASP sites).
So my question is twofold:
Why is this request not being caught by the usual .NET error handling and the custom error page served as a result?
Why do I only see this happen at MaximumASP - I can't reproduce an HTTP 400 with that pattern in any other IIS/ASP.NET environment.
http://msdn.microsoft.com/en-us/library/s57a598e.aspx
ASP.NET 4 also enables you to configure the characters that are used
by the URL character check. When ASP.NET finds an invalid character in
the path portion of a URL, it rejects the request and issues an HTTP
400 (Bad request) status code. In previous versions of ASP.NET, the
URL character checks were limited to a fixed set of characters. In
ASP.NET 4, you can customize the set of valid characters using the new
requestPathInvalidChars attribute of the httpRuntime configuration
element, as shown in the following example:
It's likely request filtering, specially it doesn't like the C: bit, fearing that it is a directory travesal attack of some sort. Many webhosts security settings will block suck a url.
A most likely guess at the the product in use is UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan
Because this filtering runs at a much lower level in the call chain, the request itself is never passed to your asp.net application process (As many of the attacks that are mitigated are designed to trick IIS into returning files outside your application folder). Thus any application defined error routines won't see it, however an IIS error page (which is what your configuring via webc.config) will be triggered.
I'm trying out the facebook c# SDK (v4.0.2) and am experiencing a 404 error when facebook tries to redirect back to the redirect handler for the SDK. The resulting URL is:
http://localhost:9152/facebookredirect.axd/elserdemo/Default.aspx?session={%22session_key%22%3A%222.GJsQK_BkApJNH8TncuFHpQ__.3600.1291665600-678938033%22%2C%22uid%22%3A%22678938033%22%2C%22expires%22%3A1291665600%2C%22secret%22%3A%22dnmnVip8JJ31rHUs2byKeQ__%22%2C%22base_domain%22%3A%22localhost%22%2C%22access_token%22%3A%22133477943366316|2.GJsQK_BkApJNH8TncuFHpQ__.3600.1291665600-678938033|xtjv95K4Lj_wg2-X3comNL4haG0%22%2C%22sig%22%3A%2241b1c3884488a9c9fa82b398c7fa80dc%22}
I have the facebook app set to iframe mode for the canvas and the necessary migrations settings in place. I've also made sure the canvas URL points to my local development server. However, when the browser tries to load the URL above, I get a 404 from ASP.NET.
If the pathinfo doesn't contain a period, it works and redirects to my app, so it appears it's the period in "default.aspx" that's screwing things up, but I'm not sure why. Any thoughts? Workarounds?
EDIT:
Although this is an issue with me with the facebook SDK, it's not specific to that. It's apparently an ASP.NET dev server issue. For example, if I try to load:
http://localhost:9152/facebookredirect.axd/elserdemo/default.aspx
I get a 404. However, if I try to load:
http://localhost:9152/facebookredirect.axd/elserdemo/default
It works, but then I end up at a facebook screen with a 404 in the iframe (because default is not a valid in my app).
EDIT #2:
This is not an issue with invalid chars in the URL. If it were, I would be receiving a 400 error code (bad request). Instead, I am receiving 404, which tells me that the dev server is trying to load a file that doesn't exist, rather than stopping at the .axd and passing off the rest as Request.PathInfo like it should. I'm not sure WHY it's doing that, so that's really what I'm looking for here.
Your app is not redirecting to the correct adress. You are getting a serialized version of a FacebookSession object instead of a querystring with a signed_request.
Make sure you are setting the correct values on the facebook app configuration page.
You have to add the redirect handler to your web.config in order for the redirect to work, just add this lines to your web.config
<system.webServer>
<handlers>
<add name="facebookredirect.axd" verb="*" path="facebookredirect.axd"
type="Facebook.Web.FacebookAppRedirectHttpHandler, Facebook.Web" />
</handlers>
Hitting reset on the previous answers.
What, exactly, is telling the browser to go to this URL: http://localhost:9152/facebookredirect.axd/elserdemo/default.aspx
I ask because Facebook should be configured to just go to http://localhost:9152/ and you indicated in the question that this happens when facebook redirects back to your site. The name of the handler shouldn't be in the URL at all which leads me to believe you've misconfigured the app within facebook itself.
Web handlers (like axd's) are executed for every incoming request automatically. If it detects that it needs to do something based on the request stream, then it will.
I got this same error - it turns out that its related to the mimetype mapped by the url's "extension." In your case, the ASP.NET development server is looking for the mimetype ".12916656....", or rather the last period to the end of the url.
If you switch to IIS on your local machine, you can set the default mimetype to application/octet-stream using the wildcard character (details at the link below). However, there's no way to do this in ASP.Net Development server:
http://support.microsoft.com/kb/326965
The 404 error and "File Not Found" exception appears to be how the server handles undefined mimetypes... quite confusing.