Is Javascript Secure?

[dredge]

Hi Everyone,

I have been asked to build a PHP application that calculates important
financial information based on some user-inputted numbers and that will

not allow the user to continue forward unless a certain percentage
range has been met. To validate the numbers, I am considering using
Javascript as opposed to having the PHP code validate the numbers
because Javascript is faster (it is almost instantaneous because the
validation code is running on the client side and does not have to wait

for a refresh, as would be required for the server-side PHP code
validation).
My question is: is Javascript secure? My concern here is that because
the Javascript validation would run on the client's computer, they
could potentially hack it to allow unacceptable financial numbers to be

submitted. Am I just being too paranoid here?
Thanks in advance,
-Karl

[Richard Cornford]

dredge wrote:
<snip>

My question is: is Javascript secure?
The unsecured thing here is the client, not the Javascript as such.
My concern here is that because the Javascript validation would run
on the client's computer, they could potentially hack it to allow
unacceptable financial numbers to be
Yes they could just hack it and send anything they wanted to the
server. There are also numerous other ways of sending anything at all
to the server (not, or not necessarily, involving javascirpt).
submitted. Am I just being too paranoid here?

_Always_ validate anything important (and most else besides) on the
server; the client cannot be trusted (even on an Intranet).

Richard.

[Lasse Reichstein Nielsen]

"dredge" <kc**@issllc.com> writes:

[validate on client instead of server]

My question is: is Javascript secure? My concern here is that because
the Javascript validation would run on the client's computer, they
could potentially hack it to allow unacceptable financial numbers to be
submitted. Am I just being too paranoid here?

No, that's exactly what they can do. (And it's not whether you are
paranoid, it's whether you are paranoid *enough*! :)

You are in a server/client setting, and the golden rule about security
in that setting is: Never trust the client!

It's not that Javascript is secure or not, it's the entire platform
that's unsafe. I can manually submit invalid data to your server using
a telnet connection, no browser needed and no Javascript runnning at
all.

If your server cannot accept certain input, *it* should test those
inputs. Nobody else can do it as well, and nobody else can be trusted
anyway.

You can still have client-side validation as a *convenience* for
normal, trustworthy users, saving the server roundtrip for each
validation, and also keep server-side validation as a *security*
measure.

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.'

[Ivan Marsh]

On Wed, 07 Jun 2006 09:16:03 -0700, dredge wrote:

I have been asked to build a PHP application that calculates important
financial information based on some user-inputted numbers and that will

not allow the user to continue forward unless a certain percentage range
has been met. To validate the numbers, I am considering using
Javascript as opposed to having the PHP code validate the numbers
because Javascript is faster (it is almost instantaneous because the
validation code is running on the client side and does not have to wait

for a refresh, as would be required for the server-side PHP code
validation).

My question is: is Javascript secure? My concern here is that because
the Javascript validation would run on the client's computer, they could
potentially hack it to allow unacceptable financial numbers to be

submitted. Am I just being too paranoid here?

I always validate the data entry with javascript and then validate data
integrity with PHP before it gets dumped into the database.

Get and post can both be spoofed whether javascript is being used or not.

--
The USA Patriot Act is the most unpatriotic act in American history.
Feingold-Obama '08 - Because the Constitution isn't history,
It's the law.

[admataz]

Hi all
It is true, while security is achievable on the server with PHP you
should never trust anything from the client side.

But don't be lured into a false sense of security and assume your data
or application is totally secure just because you're using server-side
logic and data. Server stored pages are also vulnerable to hacks and
you must protect yourself against these. PHP is considered by some to
be vulnerable to bad programming in this sense - make sure you cover
youreself.

This recent opinion piece summarises these concerns quite well.
http://blog.develix.com/frog/user/cl...e/2006-06-06/1

-ad

Ivan Marsh wrote:

On Wed, 07 Jun 2006 09:16:03 -0700, dredge wrote:

I have been asked to build a PHP application that calculates important
financial information based on some user-inputted numbers and that will

not allow the user to continue forward unless a certain percentage range
has been met. To validate the numbers, I am considering using
Javascript as opposed to having the PHP code validate the numbers
because Javascript is faster (it is almost instantaneous because the
validation code is running on the client side and does not have to wait

for a refresh, as would be required for the server-side PHP code
validation).

My question is: is Javascript secure? My concern here is that because
the Javascript validation would run on the client's computer, they could
potentially hack it to allow unacceptable financial numbers to be

submitted. Am I just being too paranoid here?

I always validate the data entry with javascript and then validate data
integrity with PHP before it gets dumped into the database.

Get and post can both be spoofed whether javascript is being used or not.

--
The USA Patriot Act is the most unpatriotic act in American history.
Feingold-Obama '08 - Because the Constitution isn't history,
It's the law.

[Dr John Stockton]

JRS: In article <11*********************@u72g2000cwu.googlegroups. com>,
dated Wed, 7 Jun 2006 09:36:51 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :

_Always_ validate anything important (and most else besides) on the
server; the client cannot be trusted (even on an Intranet).

Not always.

One cannot do that if the server merely dispenses pages and does not
receive any return data.

One need not do that if correct operation is in the user's interest;
indeed, in that case the user might wish to validate the page code
itself somehow.

Remember : there is life outside of commercial trading.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Lasse Reichstein Nielsen]

Dr John Stockton <jr*@merlyn.demon.co.uk> writes:

JRS: In article <11*********************@u72g2000cwu.googlegroups. com>,
dated Wed, 7 Jun 2006 09:36:51 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :

_Always_ validate anything important (and most else besides) on the
server; the client cannot be trusted (even on an Intranet).
Not always.

One cannot do that if the server merely dispenses pages and does not
receive any return data.

Well, then "anything important" is trivially validated :)
One need not do that if correct operation is in the user's interest;
indeed, in that case the user might wish to validate the page code
itself somehow.

Remember : there is life outside of commercial trading.

Absolutely. Only when false data sent to the server can in some way
hurt the server owner, or other users, is it necessary to protect it
against a malicious user. If all the malicious user can do is to hurt
himself, then by all means give him rope enough to hang himself.

On the other hand, input validation can also, potentially, catch the
odd input that is really an attempt at a buffer overflow or SQL
injection attack, one that you didn't know about. If you treat input
programmatically in any way, or pass it to third party components of
any sort, better be safe than sorry. You might not know whether you
can be hurt. Crashing a server doesn't only hurt the person doing it,
but also all other users wanting to use it (denial of service).

If you touch user input with a ten foot pole, validate it first. It
might just be designed to break the pole :)
/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.'

[John G Harris]

In article <tL**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writes

JRS: In article <11*********************@u72g2000cwu.googlegroups. com>,
dated Wed, 7 Jun 2006 09:36:51 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :

_Always_ validate anything important (and most else besides) on the
server; the client cannot be trusted (even on an Intranet).
Not always.

One cannot do that if the server merely dispenses pages and does not
receive any return data.

You snipped the word 'submitted'; your comment doesn't apply here.
One need not do that if correct operation is in the user's interest;
indeed, in that case the user might wish to validate the page code
itself somehow.
Not always.

The user could be following a (possibly malformed) link in a news
article, not knowing any better.
Remember : there is life outside of commercial trading.

Returning misleading advice is still unethical even if given outside
commercial trading.

John
--
John Harris