Vault Web Client error due to dangerous password

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Vault Web Client error due to dangerous password

Post by GregM » Fri Oct 08, 2004 10:21 am

I get this error trying to log into the Vault Web Client, apparently because my password contains characters that something considers dangerous. This is 2.0.6 running on 2003 Web Edition.

Server Error in '/VaultService' Application.
--------------------------------------------------------------------------------

A potentially dangerous Request.Form value was detected from the client (pass="****VALUE REMOVED****").
Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (pass="****VALUE REMOVED****").

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected from the client (pass="****VALUE REMOVED****").]
System.Web.HttpRequest.ValidateString(String s, String valueName, String collectionName) +230
System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, String collectionName) +99
System.Web.HttpRequest.get_Form() +121
System.Web.UI.Page.GetCollectionBasedOnMethod() +70
System.Web.UI.Page.DeterminePostBackMode() +47
System.Web.UI.Page.ProcessRequestMain() +2088
System.Web.UI.Page.ProcessRequest() +218
System.Web.UI.Page.ProcessRequest(HttpContext context) +18
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +179
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87




--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Mon Oct 11, 2004 9:19 am

Do you have a < or > in your password?

By default ASPNET prevents these characters from being submitted in a web form.
Mary Jo Skrobul
SourceGear

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Mon Oct 11, 2004 1:59 pm

Yes, that's exactly the problem. Any idea how to fix this?

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Mon Oct 11, 2004 2:36 pm

The simplest thing to do would be to Change your password so it doesn't have the invalid characters.

You can do this from the Vault GUI Client under Tools->Change Password.
Mary Jo Skrobul
SourceGear

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Mon Oct 11, 2004 6:48 pm

Assuming that's not an option (all the other clients accept this as a valid password), what next?

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Post by ericsink » Mon Oct 11, 2004 7:39 pm

GregM wrote:Assuming that's not an option (all the other clients accept this as a valid password), what next?
I'm confused. You're saying that "all the other clients accept this as a valid pasword". That fine, but how does this fact render our suggested workaround as "not an option"?
Eric Sink
Software Craftsman
SourceGear

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Mon Oct 11, 2004 7:53 pm

It was just an observation. The password is perfectly valid everywhere I use it, except for here.

Sure, I could change my password, but then someone else changes their password to something that the web server considers unsafe, and we're right back where we started again.

I use "special characters" in my passwords, and I don't want to have to keep changing passwords every time I come up with a combination that the web server doesn't like.

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Tue Oct 12, 2004 8:43 am

Your password doesn't work for the Vault Web login because Vault Web is an ASPNET application, the rest of Vault is not.

As far as I know, the only characters that are not allowed to be submitted in ASPNET forms are < and >. This is to prevent people from submitting a script tag to a web form that contains malicious content that could compromise your site.

If you don't want to change your password, you can turn off request validation for the action_login.aspx page. We do not recommend that you do this because it does introduce a security risk.

To turn off request validation put validateRequest="false" in the page directive at the top of the action_login.aspx page. This page is on the Vault Server machine in the VaultService/VaultWeb directory.

Your page directive for action_login.aspx would look like this:

<%@ Page language="c#" Codebehind="action_login.aspx.cs" validateRequest="false" AutoEventWireup="false" Inherits="VaultService.VaultWeb.action_login" %>

Again, the simplest and safest solution would be to just change your password.
Mary Jo Skrobul
SourceGear

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Tue Oct 12, 2004 10:10 am

Any chance that this will be fixed in 3.0 to handle any password? (i.e. The validation will be turned off by default, and Vault will do its own validation?)

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Tue Oct 12, 2004 10:35 am

Unfortunately the fix for this probably will not make it into 3.0 since 3.0 is feature complete right now.

I will log this as a bug to fix in a future release.
Mary Jo Skrobul
SourceGear

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Tue Oct 12, 2004 12:44 pm

Thanks.

Locked