Are ASP.net contact forms subject to form spamming as much as PHP ones?

[darrel]

We built out own CMS a few years ago. One of the features was a contact
form. Nothing fancy, just a handful of form fields (name, address, etc) that
when submitted, I grab and then send to a recipient via the SMTP server I
specify. Works great.

What I find odd is that in the years it's been up there, we haven't been
subject to any form-spamming.

This seems like a huge issue for a lot of PHP-based forms and you find all
sorts of workarounds to try and stop blocking.

My question is if ASP.net are naturally less vulnerable to this, or if we've
just been lucky. If the former, why? If the latter, what are some
best-practices to avoid it from happening?

-Darrel

 

[Guest]

Darrel,
A form is a form - is a form, regardless of the server-side technology
behind it.
With ASP.NET you have validation controls, "enableEventValidation" and other
features that make it more difficult to spam a form, but these techniques can
be certainly be used with any technology.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

 

[darrel]

With ASP.NET you have validation controls, "enableEventValidation" and

other
features that make it more difficult to spam a form, but these techniques
can
be certainly be used with any technology.

So, we've just been lucky?

The main issue PHP folks seem to have is bots posting data to the form
directly, and then having to write scripts to make sure the form is only
submitted from the page that has the form.

Does ASP.net's viewstate somewhat prevent people from being able to
'postback' directly to a page?

-Darrel

 

[Juan T. Llibre]

You can't post to any aspx page that isn't the page requested,
unless you have specifically configured in code the ability to do that.

 

[darrel]

You can't post to any aspx page that isn't the page requested,

unless you have specifically configured in code the ability to do that.

Ah! I bet that, alone, is the main issue with PHP forms.

-Darrel

 

[Mark Rae [MVP]]

The main issue PHP folks seem to have is bots posting data to the form
directly, and then having to write scripts to make sure the form is only
submitted from the page that has the form.

In addition to what Peter and Juan have said, there are specific techniques
which will (virtually) eliminate form-based spam, e.g. using a dynamically
generated CAPTCHA image:
http://www.markrae.net/net/mail.aspx

Does ASP.net's viewstate somewhat prevent people from being able to
'postback' directly to a page?

In this particular case, yes it does because not only must the CAPTCHA
textbox be filled in, but its contents must also match a variable held in
ViewState, which is something that a spam bot can never know...

And, while we're on the subject of reducing spam, another indespensible
technique is never to render or display email addresses in plain text -
instead, obfuscate them e.g. http://www.kcityradio.co.uk
Hover your mouse over the "Contact K-City" hyperlink and look at the status
bar - there's the email address for *you* to see, but a robot will never be
able to find it - do a View Source and you'll see what I mean...

 

[darrel]

In addition to what Peter and Juan have said, there are specific

techniques which will (virtually) eliminate form-based spam, e.g. using a
dynamically generated CAPTCHA image:
http://www.markrae.net/net/mail.aspx

And, while we're on the subject of reducing spam, another indespensible
technique is never to render or display email addresses in plain text -
instead, obfuscate them

The problem with both of those techniques is that they tend not to meet
accessibility guidelines. Not to mention Captchas are just plain annoying.
;o)

My main confusion is that it seems as if spam via PHP forms is an incredibly
common thing and that as soon as you put up a PHP contact form, you're
likely to get hit with form spam. I put up the ASP.net contact form with no
special security and we've never had one single spam come through on it.

Sounds like ASP.net by default not allowing you to post data to it directly
is the reason that it's not as big of a deal as it might be in PHP.

-Darrel

 

[Guest]

I think we might be missing the point here. A form, once sent out to the
browser, is just that - an HTML FORM. How it was created - whether PHP,
Classic ASP, or ASP.NET simply does not come into the picture. What I and
others are saying is that there are techniques and features built into
ASP.NET that make it easier to prevent form spam. But a browser or an
automated "bot" that's attempting to spam a form has absolutely no knowledge
how that form was generated - all it knows is that there is an HTML Page with
a form element in it. It's what you do when the form has been POST-ed that
prevents spamming.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

 

[George Ter-Saakov]

Actually, you site should be susceptible to the same amount of "form spam"
as php site. Depends on visibility in search engines of course.

But you got lucky, by default .NET checks and validates the viewstate of
the form and if it's not correct then it throws an exception and that get
logged in to NT event log

you can disable it if you want.
<pages validateRequest="false" enableEventValidation="false"
viewStateEncryptionMode="Never">


George.

 

[darrel]

But a browser or an

automated "bot" that's attempting to spam a form has absolutely no
knowledge
how that form was generated - all it knows is that there is an HTML Page
with
a form element in it. It's what you do when the form has been POST-ed that
prevents spamming.

Right. And I think the difference is that ASP.net, by default, will not
accept POST data unless it comes from the page itself (ie, postback). Sounds
like PHP has no such automated check. Theory being that most form spam is
coming from bots that take advantage of POSTing data directly to the page
itself.

-Darrel

 

[darrel]

But you got lucky, by default .NET checks and validates the viewstate of

the form and if it's not correct then it throws an exception and that get
logged in to NT event log

Ah! Well, I should check the event log then. Good tip!

-Darrel

 

[George Ter-Saakov]

Not sure why do you want to find them.
But trust me they are there.
I am receiving an email from my online application (around 3000 users a day)
every time 500 error happened. And I see around 3-4 robot submitted forms
(they generate 500 error with exception "Invalid ViewState") every day.

The key is that .NET does almost all clicks with __doPostBack JavaScript
method. And robots the simply submitting forms. Thus allowing .NET to
differentiate (non intentionally, I guess) between robots and humans.

George.

 

[darrel]

The key is that .NET does almost all clicks with __doPostBack JavaScript

method. And robots the simply submitting forms. Thus allowing .NET to
differentiate (non intentionally, I guess) between robots and humans.

possibly, though our forms are all standard Submit buttons (gotta be
accessible) which leads be to believe that it's because most spam bots do
not actually submit the page itself, but rather just send post data to
directly to the page. Sounds like without a matching viewstate, ASP.net
pages just error out and log it.

-Darrel

 

[Juan T. Llibre]

Another important consideration is that ASP.NET checks
to see whether the data sent to it IsPostback to the form.

If it's not a postback, i.e., if it's a POST from a page which is not itself,
and which resides outside the AppDomain, the POST will not be accepted.

There's a mechanism called cross-page posting which allows aspx pages
to post to other aspx pages, but you cannot post to aspx pages from outside
the Application's AppDomain.

The Page class exposes a property named PreviousPage.

If the source page and target page are in the same ASP.NET application,
the PreviousPage property in the target page contains a reference to the source page.
(If the page is not the target of a cross-page posting, or if the pages are in different applications,
the PreviousPage property is not initialized.)

If the source and target page are in different applications, you cannot directly get the
values of controls on the page, but you can read the posted data from the Form dictionary.

You cannot read view state from the source page, because it is hashed.

If you want to store values in the source page and make them available in a target page in another
application, you can store the values as strings inside hidden fields on the source page and
access them through Request.Form on the target page.

Using the reference in the PreviousPage property, you can search for controls on
the source page and extract their value. You typically do this with the FindControl method.

If there's no reference to FindControl, or to PreviousPage, or to the originating application,
or if the ViewState is unreadable, ASP.NET will ignore the POST, causing the form spam to fail.

So, in a nutshell, that is why ASP.NET is less vulnerable to form-spamming than PHP.

 

[darrel]

So, in a nutshell, that is why ASP.NET is less vulnerable to form-spamming

than PHP.

Thank you for that detailed analysis! That explains it!

-Darrel