form-checkers to filter "link-spamming"

[Claude]

Hi,

I've designed my own form checking code for name, address, email, comment
box etc.
What my client keeps getting in his consumer feedback forms is "spam" from
companies who
repeatedly insert their hyperlinks in all fields, of course along with their
"hype"...

Is is possible with Javascript to refuse form contents whose strings contain
URL's?
(or would this involve reg ex which I've got a total mental block against?
:)
Claude

[web.dev]

Claude wrote:

Hi,

I've designed my own form checking code for name, address, email, comment
box etc.
What my client keeps getting in his consumer feedback forms is "spam" from
companies who
repeatedly insert their hyperlinks in all fields, of course along with their
"hype"...

Is is possible with Javascript to refuse form contents whose strings contain
URL's?
(or would this involve reg ex which I've got a total mental block against?
:)

You can, however consider the following. What if, these "spammers"
turn off javascript? Your javascript would not work in this case.

Solution: Do the check on both the client side AND server side.

[Claude]

You can, however consider the following. What if, these "spammers"
turn off javascript? Your javascript would not work in this case.

Solution: Do the check on both the client side AND server side.

thanks web.dev ...

have done a lot of google searching on this subject --> did find out that
it's called "comment spam", ie, related to spamming user input forms, but
all of what's on the net seems to relate to "comment spamming" in Blog
software (WordPress, Moveable Type, especially). And of course, spam robots
harvesting email addresses. there's actually very few solutions offered for
people that insert hyperlinks into web-forms.

Claude

[RobG]

Claude wrote:

You can, however consider the following. What if, these "spammers"
turn off javascript? Your javascript would not work in this case.

Solution: Do the check on both the client side AND server side.

thanks web.dev ...

have done a lot of google searching on this subject --> did find out that
it's called "comment spam", ie, related to spamming user input forms, but
all of what's on the net seems to relate to "comment spamming" in Blog
software (WordPress, Moveable Type, especially). And of course, spam robots
harvesting email addresses. there's actually very few solutions offered for
people that insert hyperlinks into web-forms.

The bottom line is that such spammers nearly always use automated
processes to send the spam, they don't sit there and fill-in the form.

So deal with it at the server - identify likely spam and either
quarantine it for review or just ditch it. Client-side script can't do
much to help you. If links are the only problem, then search for
URI-like strings in text fields, e.g. "http://".

Blog software has built-in comment spam tools, if you are just using a
form, then you should implement something similar, e.g. introduce a
'confirm' page, require all comments to be reviewed before they are
posted, etc.
--
Rob

[Jasen Betts]

On 2006-01-19, Claude <am***@amour.com> wrote:

Hi,

I've designed my own form checking code for name, address, email, comment
box etc.
What my client keeps getting in his consumer feedback forms is "spam" from
companies who
repeatedly insert their hyperlinks in all fields, of course along with their
"hype"...

Is is possible with Javascript to refuse form contents whose strings contain
URL's?

not on the client side, is the server using javascript?
--

Bye.
Jasen

[Claude]

>> Is is possible with Javascript to refuse form contents whose strings

contain
URL's?

not on the client side, is the server using javascript?

Hi Jasen,

isn't JS a client-side scripting only (ie interpreter built into browser)?
Are you thinking of Java?

I'm new at JS, and most of the JS I utilize has been sewn together,
modified, and customized out of snippets I find on the 'net. From what I
know, it seems that JS should be able to parse the string contents of a text
input box/area for both "www" and "http", and if found, return an alert box
that arrests execution until a "clean" string is submitted. (actually it
would be better if it booted the 'bot' right off the site!)

this seems like kind of a no-brainer. It's just that I cringe at reg/ex and
there's no way I can embrace learning it at this point. if anyone here
wants to earn a few bucks thru paypal by designing a JS snippet that will
parse input strings in a form validation function as above, leave me your
email.

Claude

[Dag Sunde]

"Claude" <am***@amour.com> wrote in message
news:ZpnAf.111579$km.104252@edtnps89...

Is is possible with Javascript to refuse form contents whose strings
contain
URL's?

not on the client side, is the server using javascript?

Hi Jasen,

isn't JS a client-side scripting only (ie interpreter built into browser)?
Are you thinking of Java?

No, Javascript is a full blown citicen of the serverside, together with
VbScript, PHP, Perl, Et.c...

Under windows, you can also use it as a shell scripting language,
using CScript.exe

<snipped/>

--
Dag.

[Lasse Reichstein Nielsen]

"Claude" <am***@amour.com> writes:

I'm new at JS, and most of the JS I utilize has been sewn together,
modified, and customized out of snippets I find on the 'net. From what I
know, it seems that JS should be able to parse the string contents of a text
input box/area for both "www" and "http", and if found, return an alert box
that arrests execution until a "clean" string is submitted. (actually it
would be better if it booted the 'bot' right off the site!)
While it is possible to make a script to test for the presence of links
in the text, it is not sufficient to prevent links from being submitted.
Merely disabling javascript would bypass the test. He could also create
his own HTTP request and send data directly to the server bypassing
your entire page.

If it is important to your server not to accept certain inputs, you
should always test that on the server. It's the only way to be sure.

You can then also test on the client, but that is only to save the
user a roundtrip to the server, when you know his input will be
rejected anyway. Client side input checking is not a security measure,
it is pure user help. It will not stop a malicious user with any
degree of technical competence.
this seems like kind of a no-brainer. It's just that I cringe at reg/ex and
there's no way I can embrace learning it at this point.

If you want to find any instance of "www" or "http" (both words that
could crop up in normal conversation, e.g. "I love the www! But I
really don't know what 'http' stands for. Anyone know?"), then the
regexp:
/\bwww\b|\bhttp\b/i
should do.

You might want to look for "www.something.something" or "http://"
or "https://" instead:
/\bwww\.([-\w]+\.)+\w{2,}\b|https?:\/\//i

But remember, test on the server for security, on the client for
usability.

Good luck.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jasen Betts]

On 2006-01-21, Claude <am***@amour.com> wrote:

Is is possible with Javascript to refuse form contents whose strings
contain
URL's?
not on the client side, is the server using javascript?

isn't JS a client-side scripting only (ie interpreter built into browser)?
Are you thinking of Java?
Microsoft have invented a way for javascript (actually J-Script(tm)) to be
used server side.
I'm new at JS, and most of the JS I utilize has been sewn together,
modified, and customized out of snippets I find on the 'net. From what I
know, it seems that JS should be able to parse the string contents of a text
input box/area for both "www" and "http", and if found, return an alert box
that arrests execution until a "clean" string is submitted. (actually it
would be better if it booted the 'bot' right off the site!)

this seems like kind of a no-brainer. It's just that I cringe at reg/ex and
there's no way I can embrace learning it at this point. if anyone here
wants to earn a few bucks thru paypal by designing a JS snippet that will
parse input strings in a form validation function as above, leave me your
email.

Most likely the application being used to spam the forms isn't running
javascript.

Javascript (client side) isn't suited to security, only to interfacce
enhancements.

Bye.
Jasen

[Lasse Reichstein Nielsen]

Jasen Betts <ja***@free.net.nz> writes:

Microsoft have invented a way for javascript (actually J-Script(tm)) to be
used server side.

Them too. Netscape had it in their web server almost from the beginning
of JavaScript's history.
Javascript dialects are now used in many places, both client, server and
stand-alone (e.g., in pdf-files).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Claude]

> Microsoft have invented a way for javascript (actually J-Script(tm)) to be

used server side.

Most likely the application being used to spam the forms isn't running
javascript.

Javascript (client side) isn't suited to security, only to interfacce
enhancements.

Bye.
Jasen

Hi Jasen,

I'm aware that J-script is different than Javascript; the former requiring
server-side execution. What I don't understand from reading the last few
posts is the concept of Javascript being a server-side app. When I debug or
"prove" my JS functions, I can do it on my local machine, no web server
req'd. But when I'm debugging PHP, I have to upload it to my web server
because that's where the PHP "interpreter" resides. Whereas the JS
"interpreter" is totally client-side. Therefore,my understanding is that
the interpretation and execution of JS is totally client-side.

Please correct me if I'm wrong.

What I assumed about JS "parsing" out and rejecting user input that
contained "www" or "http" is that the form could not be "submitted" without
invoking the "onsubmit" function which would perform this action of
filtering. The target email address that the form is POSTed to is not
visible on my form - it's a coded variable that fetches a "real" email
address from the CGI script, which is not readable by visitors or spam-bots.

Admittedly, my knowledge of serverside protocol is very rudimentary, but I'm
hoping some of you can "enlighten" me thus-wise!

claude

[Lasse Reichstein Nielsen]

"Claude" <am***@amour.com> writes:

I'm aware that J-script is different than Javascript; the former requiring
server-side execution.
That is incorrect.
JScript is a language developed by Microsoft. It implements the
ECMAScript standard and is mostly compatible with Netscape Corp.'s
JavaScript language.
JScript is the language used to execute web-page scripts in IE with
types both text/javascript and text/jscript.
It is also available as one of the languages one can write ASP pages
in (although the newest versions of ASP uses JScript.net)

Obviosuly, the environment will be different whether the JScript
script is being run as part of a web page in a browser, as part
of an ASP page on the server or as a stand-alone script using
the windows scripting host.

Microsoft has an overview of the versions of JScript:
<URL:http://msdn2.microsoft.com/2z6exc9e.aspx>
It shows which versions comes with which other product, be it
a browser, a web server, or an operating system.
What I don't understand from reading the last few posts is the
concept of Javascript being a server-side app. When I debug or
"prove" my JS functions, I can do it on my local machine, no web
server req'd. But when I'm debugging PHP, I have to upload it to my
web server because that's where the PHP "interpreter" resides.
Whereas the JS "interpreter" is totally client-side. Therefore,my
understanding is that the interpretation and execution of JS is
totally client-side.
It can be server-side if you want it (and have IIS available).
However, the script you write for the server-side environment should
not be the same as you write for a web-client.

What I assumed about JS "parsing" out and rejecting user input that
contained "www" or "http" is that the form could not be "submitted" without
invoking the "onsubmit" function which would perform this action of
filtering.

Normally, no, but it takes nothing fancier than having Javascript
turned off in the browser to bypass the onsubmit function.

Client-side scripting cannot be used to ensure security, since the
client controls the script. A malicious client can omit or modify
the script in any way it wants to.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jasen Betts]

> Hi Jasen,

I'm aware that J-script is different than Javascript; the former requiring
server-side execution. What I don't understand from reading the last few
posts is the concept of Javascript being a server-side app. When I debug or
"prove" my JS functions, I can do it on my local machine, no web server
req'd. But when I'm debugging PHP, I have to upload it to my web server
because that's where the PHP "interpreter" resides. Whereas the JS
"interpreter" is totally client-side. Therefore,my understanding is that
the interpretation and execution of JS is totally client-side.

Please correct me if I'm wrong.
those locations are only the locations of the interpreters that you are
using.

it's possible to download a PHP executable and run it from the command-line
(I suppose that's stand-alone not client side)

similarly some web servers support javascript (etc) for generating
pages.
What I assumed about JS "parsing" out and rejecting user input that
contained "www" or "http" is that the form could not be "submitted" without
invoking the "onsubmit" function which would perform this action of
filtering.
but it can, either by editing the form, disabling scripting, or by using a
different application (eg wget or curl) to do the submissions.
The target email address that the form is POSTed to is not
visible on my form - it's a coded variable that fetches a "real" email
address from the CGI script, which is not readable by visitors or spam-bots.
Where can I see this form?

Does this address vary or it it always the same.. is there any sort of
encryption of obfuscation of the address...

when submitting form content by email mozilla gives me the option of editing
the content after the submit action but before it is sent.
Admittedly, my knowledge of serverside protocol is very rudimentary, but I'm
hoping some of you can "enlighten" me thus-wise!

Bye.
Jasen