Recently, the VTdotNET website has been getting hit by some robot entering hyperlinks into the password text box of the login form.

ASP.NET catches this on the server side and pushes out this error:

System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (ctl00$ContentPlaceHolder1$LoginView1$Login1$Password=”<A href=http://…”).

Since I have errors emailed to me, I’m getting a LOT of these emails every day which was annoying.

So, I wanted to trap this on the client side using a validator.

While they may appear to be, login controls are not totally locked up. One of the smart tag options is to “Convert to Template”. Once you do this, you can edit the control all you want.

So I added a RegularExpressionValidator control and entered the following regex for the ValidationExpression:

^((?!href|http).)+$

which won’t allow strings that href or http. Then tied it to the password control and to the ValidationGroup for the whole login control. That way I get the validation during data entry AND when the user hits the login button.

I did the same for the User Name control.

This solved part of the problem. If you went to the actual login page, it was no longer possible to enter hyperlinks and postback. But the spam kept coming. I changed the name of the controls and put some more details in the error handler and saw that the name of the control reported in the error didn’t change and that it wasn’t even coming from the login page. But it was the ONLY login control in the entire website.

Then I got a little education from some who are less naive than I about the evil ways of spammers. Ryan Trudelle-Shwarz, Adam Sills and Dave Wanta filled out the picture for me. It’s a nasty type of comment spam where a robot collects the postback info from your site and no longer needs to return there to do the actual entry and postback. There is still some mystery here for me since there never was a login control on the home page, but as Ryan suggested, the simplest thing to do is just filter out those errors so that I don’t have to get them in my email box and forget about them.

ASP.NET Forum user keanxsoul has done some detective work along these lines and offers an interesting explanation about how the spammers are actually doing this.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!