Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #22409 > unrolled thread

contact page spammed

Back to article view | Back to comp.lang.javascript

Contents

  contact page spammed Andrew Poulos <ap_prog@hotmail.com> - 2013-12-26 16:34 +1100
    Re: contact page spammed "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-12-25 22:23 -0800
      Re: contact page spammed Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-12-26 07:45 +0100
    Re: contact page spammed Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-26 18:40 +0000

#22409 — contact page spammed

There's a contact page that I help maintain. Users enter some text (a 
message) into a text field, and then click the submit button. The text 
is processed and sent to a server page which generates an email.

Any message that contains a URL (ie. contains "http://" or "https://") 
is ignored.

I use this to find URLs

var val = 
document.forms['frmEnquiry'].elements['comments'].value.toLowerCase();
if ((val.indexOf("http://") != -1 ) ||
     (val.indexOf("https://") != -1 )) {
     // ignore stuff here
}

Lately we've been receiving emails that contain URLs. The URLs in the 
email are all of the form

   Some text <a href=" http://www... ">blah</a>...
(There's a space between the double quotes and the URL)

Looking at the source for the email does not reveal any encoding of the 
URLs. How could they have managed to get around the search for "http://"?

Andrew Poulos

[toc] | [next] | [standalone]

#22410

On Wednesday, December 25, 2013 11:34:40 PM UTC-6, Andrew Poulos wrote:
> There's a contact page that I help maintain. Users enter some text (a 
> message) into a text field, and then click the submit button. The text 
> is processed and sent to a server page which generates an email.
> 
> Any message that contains a URL (ie. contains "http://" or "https://") 
> is ignored.
> 
> I use this to find URLs
> 
> var val = 
> document.forms['frmEnquiry'].elements['comments'].value.toLowerCase();
> 
> if ((val.indexOf("http://") != -1 ) ||
>      (val.indexOf("https://") != -1 )) {
>      // ignore stuff here
> }
> 
> Lately we've been receiving emails that contain URLs. The URLs in the 
> email are all of the form
> 
>    Some text <a href=" http://www... ">blah</a>...
> (There's a space between the double quotes and the URL)
> 
> Looking at the source for the email does not reveal any encoding of the 
> URLs. How could they have managed to get around the search for "http://"?

Disable JavaScript or post directly without using the form? You can't avoid using server side validation

[toc] | [prev] | [next] | [standalone]

#22412

Michael Haufe (TNO) wrote:

> On Wednesday, December 25, 2013 11:34:40 PM UTC-6, Andrew Poulos wrote:
>> There's a contact page that I help maintain. Users enter some text (a
>> message) into a text field, and then click the submit button. The text
>> is processed and sent to a server page which generates an email.
>> 
>> Any message that contains a URL (ie. contains "http://" or "https://")
>> is ignored.
>> 
>> I use this to find URLs
>> 
>> var val =
>> document.forms['frmEnquiry'].elements['comments'].value.toLowerCase();
>> 
>> if ((val.indexOf("http://") != -1 ) ||
>>      (val.indexOf("https://") != -1 )) {
>>      // ignore stuff here
>> }

It is not a good idea to consider all messages containing URIs to be spam.

>> Lately we've been receiving emails that contain URLs. The URLs in the
>> email are all of the form
>> 
>>    Some text <a href=" http://www... ">blah</a>...
>> (There's a space between the double quotes and the URL)

Syntactically wrong, easy to spot.

>> Looking at the source for the email does not reveal any encoding of the
>> URLs. How could they have managed to get around the search for "http://"?
> 
> Disable JavaScript or post directly without using the form?

You can make it harder for spammers by using authentication tokens and 
*pseudo*-CAPTCHAs – which do *not* do what they claim to – …

> You can't avoid using server side validation

… but, in general, that is correct.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#22415

On Thu, 26 Dec 2013 16:34:40 +1100, Andrew Poulos wrote:

> There's a contact page that I help maintain. Users enter some text (a
> message) into a text field, and then click the submit button. The text
> is processed and sent to a server page which generates an email.
> 
> Any message that contains a URL (ie. contains "http://" or "https://")
> is ignored.
> 
> I use this to find URLs
> 
> var val =
> document.forms['frmEnquiry'].elements['comments'].value.toLowerCase();
> if ((val.indexOf("http://") != -1 ) ||
>      (val.indexOf("https://") != -1 )) {
>      // ignore stuff here
> }
> 
> Lately we've been receiving emails that contain URLs. The URLs in the
> email are all of the form
> 
>    Some text <a href=" http://www... ">blah</a>...
> (There's a space between the double quotes and the URL)
> 
> Looking at the source for the email does not reveal any encoding of the
> URLs. How could they have managed to get around the search for
> "http://"?

It's simply not safe to rely on client side processing for this sort of 
data validation and verification. It should be happening in the server 
side script.

By using any one of a number of tools (wget, nc, a web browser, any 
language that interfaces to the curl libraries etc) I can completely 
bypass your javascript client based checking, and in several cases I can 
do it in a script that could generate several hundreds or even a few 
thousands of requests per hour.

You need to put your validation and verification in your server side form 
processing email script. Anything that you do in the client side is 
simply for the convenience of the user, eg to warn them that the 
submitted message will not be accepted. Anything that you think you're 
doing with client side javascript to perform some sort of data validation 
or verification is a waste of time and effort, because there are so many 
ways to bypass it.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web