I found in the error logs of my website requests made to URLs containing invalid characters. The URLs that are requested are made of pieces of code, e.g:
/Templat<div class="right-se
*The URLs are always a mix of pieces of code. Different parts from different places in the same page. Liket the example above, which the first part is a path to the CSS file and the second is a HTML tag.
I have been analyzing all the errors found to try to find a pattern, but no luck. They happen in different pages, of different types.
The only two pattern I seem to find is that all the URLs or most of the start with '/Templates' or a piece of that text '/T' and that all the errors are in IE7 and IE8
This is the error shown in the logs:
Class and function: Global.asax.Application_Error
Exception type:
Message: RawUrl: /T <div id=
Referrer path and query: /aboutus
User web browser: IE. Version: 8.0.
A potentially dangerous Request.Path value was detected from the client (<).
Stack trace: at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
I have not been able to reproduce the error in the test environment or production, and don't know really where to start looking at my code.
The website is made in ASP .NET running in IIS7 with .NET 4.0
Thanks
ASP .Net does a request validation for preventing different "hacking" attacks. When an input looks like that, it raises these errors.
Many crawlers scan websites, some might be asked to do this (your company paid for) other simply to find vulnerabilities and exploit them. The requested URLs might not look with something you have in the sitemap.
Related
I have a browser-based InfoPath 2010 form. I'm getting an error opening the form in one environment. It works in at least three other environments. The error is:
The form template failed to load... Type: XmlException, Exception Message: For security reasons DTD is prohibited in this XML document. To enable DTD processing set the ProhibitDtd property on XmlReaderSettings to false and pass the settings into XmlReader.Create method.
I have seen this question posted around the Web, but the answers are vague and varied and are centered around products besides InfoPath. We also have other forms working in the environment where this form is failing, so it's something related to this particular form in this particular environment.
Problem solved. The error message was misleading, but turns out one of the data connections had a URL pointing to the wrong SharePoint farm. It was supposed to be pointing to the local form library. Cross platform calls tend not to work.
Basically make sure that the domain name in the connection file is matching the domain name where you're publishing your form.
For example, if your InfoPath form is located in:
https://extranet.MySiteName.com/The-Rest-Of-Your-Domain-Name
then make sure that all the domains (in this example extranet.MySiteName.com/)
in your data connection file match. The connection file line may look similar to this:
<udc:Query>
https://extranet.MySiteName.com/_vti_bin/My-WCF-Services/My-Data-ServiceName.svc/
</udc:Query>
I added WebResource.axd (empty file) manually in production environment (IIS7 and Windows Server 2008) after chrome and firefox was giving error 404 for WebResource.axd. And now it is working fine, even with parameters. I am not sure why ASP.NET generating this script in final render result (no problem with VS2008), but now it is working. I want to know, is there any security implications other than what normally associated with WebResource.axd as it is in root directory?
Thanks
I also had this issue recently, after a code change WebResource.axd stopped working for my site. Basically, it exposes dynamic resources over http. For a longer explanation visit:
Just where is webresource.axd?
Typically, what happens is that one of the dynamic resources being requested has failed, but the resource name is encrypted. This blog post will help you decrypt the name, use it and the query string of your failing webresource.axd?___ request to figure out where the error is coming from.
Telerik webresource troubleshooting
I am currently migrating from Tridion R5.3 to Tridion 2011. I am having issues with serving some pages through the presentation server. For reference all of my web pages are classic ASP and I am running them on IIS7.5.
I have have a page located at http://www.example.com/widget/index.asp. When I first access the page I get a The page cannot be displayed because an internal server error has occurred., if I then refresh the page it loads fine, if I refresh the page a third time it comes up with the error. The page works every other request.
I have enabled Failed Request Tracing on my website and I am getting the error
ASP_LOG_ERROR
LineNumber: 87
ErrorCode: 800706be
Description:
Note there is no description.
The code being called is
85: Dim objTranslationPageLink
86: Set objTranslationPageLink = Server.createObject("cd_link.PageLink")
87: strTranslatedPageLink = objTranslationPageLink.GetLinkAsString("tcm:0-12-1", "tcm:12-123456-64", "", "", "TranslationFound", False)
88: Set objTranslationPageLink = Nothing
It looks like there is no problems creating the cd_link.PageLink object, just when calling the GetLinkAsString(...) function.
I use the cd_link.PageLink object in lot of other pages with no problems but it seems with pages that use this specific piece of code experience the problems.
I was thinking it could be something to do with caching pages however I turned off caching of ASP pages (IIS7 > ASP > Services > Caching Properties) and still had the problem.
Any ideas?
edit1
The code worked fine on Windows Server 2003 IIS6. I am trying to make it work on Windows Server 2008 IIS7.
edit2
It appears that the page is creating a lot of cd_link.ComponentLink and cd_link.PageLink objects. I have a test page in which I create 10 ComponentLink objects I get the error (every other page) but if I reduce this to 5 ComponentLink objects it works every time.
edit3
My cd_core.xxxx.xx.xx.log has the following errors
2012-11-02 11:55:34,027 ERROR XMLConfigurationReader - Error while validating file 'cd_link_conf.xml' with schema 'schemas/cd_link_conf.xsd'. cvc-complex-type.3.2.2: Attribute 'DefaultRootLocation' is not allowed to appear in element 'Publications'.
edit4
Thanks for bearing with me. The problem I was having with my cd_link_config is fixed and doesn't appear to have been be related. I now have no errors in my any of the four log files (cd_core, cd_deployer, cd_monitor, cd_transport) but the original issue persists.
Looks like you are running the CD Link windows service and the following hotfix might help to resolve your issue. I have not tried this hotfix but the description says Page link fails on second attempt of accessing the page, so that means it might work sproadically depending on the logger memory resources.
Anyway worth looking at this hotfix : CD_2011.1.0.78355
Description: The Linking windows service was not correctly cleaning up a logger memory resource on certain windows platforms
It is a long time since I worked with Classic ASP and SDL Tridion, but double check the following
Is the linking service running on the server?
Check your cd_licenses.xml file is in place
Validate that you have a correct cd_link_conf.xml and cd_storage_conf.xml (these changed from 5.3 I believe)
Look in the Application and Tridion event logs for clues
The Tridion linking log files
That error code seems to imply that the Linking DLL is not registered properly.
That is all I can think of for now.
I didn't realise that 2011 actually schema-validates the config files, but in any case, now the error is clear. I'd suggest doing the validation yourself in an XML editor such as XML Spy. That should point out exactly what's wrong with the configuration file.
To routinely check your configurations, you may find it interesting to script it as described here.
This is related to a previous (unanswered) issue I've had with trying to catch request errors in the Global.asax, but it now appears to be more widespread.
The URL redirect feature in IIS7 will not handle URLs which both end in .aspx and contain a colon anywhere in the url. Rather than follow its own redirect rules, IIS7 treats .aspx pages differently to others, and throws
[NotSupportedException: The given
path's format is not supported.]
Has anyone else encountered this issue?
Possibly IIS is treating the colon as if it should precede a port number (http://mysite.com:12345) or some other invocation to an IIS- or OS-level command. So, it may be suspicious of some kind of code injection.
You might try this thread: Why is using a URL containing a colon considered as a "potentially dangerous request"? .
Hanselman also had an interesting bit up about url rewriting black magic - check the middle of the article for more on the colon character. http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx
Sometimes I get 400 Bad Request error for different websites written on ASP.NET.
The only solution I know is to clean up cookies for that site. Seems like that the cause of problem is _utmz and _utma cookies, which belong to Google Analytics. The problem is occurs in common cases in Mozilla FireFox, sometimes on Ghrome and Safari and never in IE. This error occurs accidentally.
What I found:
From Stefan on the ASP.Net team:
http://forums.asp.net/p/1431148/3221542.aspx
In current versions of ASP.NET Urls
containing characters like the colon
character will be rejected as a
potential security threat. The
historical reason for this is that the
underlying NTFS file system supports
alternate resource streams that can be
accessed with names like
"yourfile.txt:hiddendata.txt".
Blocking the colon character from Urls
prevents poorly written applications
from accidentally working with
alternate resource streams.
There is also a limitation in current
versions of ASP.NET that incoming Urls
need to map to the NTFS file system
for purposes of determining managed
configuration data.
In ASP.NET 4 these limitations can be
optionally removed. However these
changes are in the Beta 2 version of
ASP.NET 4 - they are not in Beta 1. We
tried out the Url listed earlier in
this forum post and confirmed that
with our internal builds of ASP.NET 4
you can use that style of Url and
process it without any 400 error.
Is is a problem with ASP.NET runtime, cookie managment process of FireFox or Google Analytics code? What problem solutions do you know?
The issue is with the way that firefox handles special characters in cookies. It doesn't have anything to do with asp.net, you will have the error whatever language you are using.
The issue seems to occur most often with Google Analytics campaign sources. You should simply try to keep the values in these to alpha characters.
I have personally had to fix issues where people used an apostrophe and an mDash in their query strings. As a result I tell people to just avoid hyphens and apostrophes all together. If you aren't the one including them, you can't be sure they didn't copy a special character the browser can't handle.
This forum has a suggestion for clearing the bad cookies on the 400 page so that they can access the site properly.
There is already another question with the same problem on stackoverflow.
You need to make sure that you are not including any special characters before you set the campaign sources etc. Sources that are created dynamically through CMS newsletters etc. can include bad characters if they are not formatted aggressively. We have had trouble with people pasting MSOffice characters into titles and links which break cookies and stop the page from being served.
There is no solution to the problem other than making sure that you aren't sending bad data to GA and causing cookies to be corrupted.