Security risk to eval?

[optimistx]

Assume:

1) A programmer has written a htlm page with javascript code, which is
loaded to and executed in client's computer.

2) The http-server, which is sending the page, does not execute php, does
not use ajax, does not use passwords, has sql-files (=the most typical
server serving simple pages to clients). http-get-requests are used.

I cannot imagine how the client could damage the server, if the loaded page
allows the client to execute any javascript code without any checking, e.g.
with eval. E.g. there could be a textarea, which the client can fill with
any js code imaginable and the contents is eval'd in client's computer.

Would this be a security risk for the server? Or for the client so that the
client could blame the programmer?

 

[Evertjan.]

optimistx wrote on 25 nov 2009 in comp.lang.javascript:

Assume:

1) A programmer has written a htlm page with javascript code, which
is loaded to and executed in client's computer.

2) The http-server, which is sending the page, does not execute php,
does not use ajax, does not use passwords, has sql-files (=the most
typical server serving simple pages to clients). http-get-requests are
used.

Not javascript related.

I cannot imagine how the client could damage the server, if the loaded
page allows the client to execute any javascript code without any
checking, e.g. with eval. E.g. there could be a textarea, which the
client can fill with any js code imaginable and the contents is eval'd
in client's computer.

A programmar [are you one?] should always be able to imagine.

Would this be a security risk for the server? Or for the client so
that the client could blame the programmer?

You are mixing the concepts of user and client making your Q nonsensical.

Everyone blames the programmer, and rightly so.
Withhout programmers, who would there be left to blame in cyberspace?

The user is always as risk,
as is his destiny as an programmingwize unintelligent being.

The client [=browser] itself is not at risk, the clientside data could be
so.

The server data are only at risk in the case of an unfavorable
hacker/manager intelligence cum knowledge index, which usually is the
case.

 

[optimistx]

optimistx wrote on 25 nov 2009 in comp.lang.javascript:


Not javascript related.

....
There was a typo in my entry, should be: NO sql- files.

 

[Gregor Kofler]

optimistx meinte:

Assume:

1) A programmer has written a htlm page with javascript code, which is
loaded to and executed in client's computer.

2) The http-server, which is sending the page, does not execute php,
does not use ajax, does not use passwords, has sql-files (=the most
typical server serving simple pages to clients). http-get-requests are
used.

SQL and no PHP (or other server side scripting)? I'm intrigued... (Or
what are "sql-files"?)

Would this be a security risk for the server? Or for the client so that
the client could blame the programmer?

Since I cannot imagine the upper "configuration", it's up to the
programmer to figure out explanations.

Gregor

 

[Gregor Kofler]

optimistx meinte:

There was a typo in my entry, should be: NO sql- files.

Ok. That makes risks pretty negligible. However, now you don't need a
"programmer" anymore. An "author" suffices.

Gregor

 

[optimistx]

Gregor Kofler wrote:
that the client could blame the programmer?

Since I cannot imagine the upper "configuration", it's up to the
programmer to figure out explanations.

Gregor

Sorry, there is a typo in my entry, should be : NO sql

 

[JR]

Assume:

1) A programmer has written a htlm page with  javascript code, which is
loaded to and executed in client's computer.

I remember creating a page like that in 2000, when I still didn't use
a server-side scripting language, such as PHP or ASP.

2) The http-server, which is sending the page, does not execute php, does
not use ajax, does not use passwords, has [NO] sql-files (=the most typical
server serving simple pages to clients). http-get-requests are used.

I cannot imagine how the client could damage the server, if the loaded page
allows the client to execute any javascript code without any checking, e.g.
with eval. E.g. there could be a textarea, which the client can fill with
any js code imaginable and the contents is eval'd in client's computer.

Would this be a security risk for the server? Or for the client so that the
client could blame the programmer?

A hacker could try a "denial-of-service" attack (http://
en.wikipedia.org/wiki/Denial-of-service_attack).
However, real hackers tend to focus efforts on things that bring them
financial return.

Cheers,
JR

 

[JR]

Assume:

1) A programmer has written a htlm page with  javascript code, which is
loaded to and executed in client's computer.

I remember creating a page like that in 2000, when I still didn't use
a server-side scripting language, such as PHP or ASP.

2) The http-server, which is sending the page, does not execute php, does
not use ajax, does not use passwords, has [NO] sql-files (=the most typical
server serving simple pages to clients). http-get-requests are used.

I cannot imagine how the client could damage the server, if the loaded page
allows the client to execute any javascript code without any checking, e.g.
with eval. E.g. there could be a textarea, which the client can fill with
any js code imaginable and the contents is eval'd in client's computer.

Would this be a security risk for the server? Or for the client so thatthe
client could blame the programmer?

A hacker could try a "denial-of-service" attack (http://
en.wikipedia.org/wiki/Denial-of-service_attack).
However, real hackers tend to focus efforts on things that bring them
financial return.

Cheers,
JR

Never mind if your page won't submit the client code to the server.

Cheers,
JR

 

[Dr J R Stockton]

Would this be a security risk for the server? Or for the client so that
the client could blame the programmer?

We do not know who you are, and we do not know who else will read this
thread.

Therefore, while we might reasonably answer "Yes" or "No", we cannot
safely justify an answer of "Yes" by explanation of details, since we
might therefore make ourselves inadvertent accessories before the act.

I do know of a fault in one current/recent browser which gives the
appearance of an untrapped exceeding of range of a form which might
allow the execution of random or arbitrary code; so my answer is
"Perhaps yes". Unfortunately the browser does not seem to offer a
secure-seeming fault reporting system.

 

[optimistx]

Dr J R Stockton wrote:
....

I do know of a fault in one current/recent browser which gives the
appearance of an untrapped exceeding of range of a form which might
allow the execution of random or arbitrary code; so my answer is
"Perhaps yes".

Thanks for the info.

Is it like this:

If the page contains a form, which is set by a post or
get http-request to the server, a malignant user of some defective
browser can fill something in
a form on a page so that server security is at risk even
in the case when the
server does not contain any code from the author to handle the
request ?

If it is so I could imagine a malignant user to construct a bookmarklet
to ANY page, where execution of javascript is allowed
and do the unspecified trick above. Even
on a page which does not contain any javascript code originally.

If it is so, me allowing the user to execute any code using eval
(constructed
by the user) does not increase the risk for the server (?).

 

[Gregor Kofler]

optimistx meinte:

Dr J R Stockton wrote:
...

Thanks for the info.

Is it like this:

If the page contains a form, which is set by a post or
get http-request to the server, a malignant user of some defective
browser can fill something in
a form on a page so that server security is at risk even
in the case when the
server does not contain any code from the author to handle the
request ?

What's a form good for, without server side scripting (which you don't
have)?

The only thing a user could do, is exploit a vulnerability in the
webserver application. When using a popular webserver (like Apache),
vulnerabilities are rare and fixed quickly.

Gregor

 

[optimistx]

Gregor Kofler wrote:
....

What's a form good for, without server side scripting (which you don't
have)?

The only thing a user could do, is exploit a vulnerability in the
webserver application. When using a popular webserver (like Apache),
vulnerabilities are rare and fixed quickly.

Gregor

ok, good to know.

One can use the input elements inside the form ( or without an actual
form)e.g.
to receive user input and store it to a cookie in user's hard disk, if
allowed.
In the next session js-code reads the cookie.

 

[Richard Cornford]

Input elements outside of forms dont conform to HTML standards,
AFAIK.

<snip>

Input elements outside of forms are fine (by HTML spec and otherwise).
They will not be involved in submitting to the server if used in that
way, but can still be used in a javascript driven UI.

Richard.

 

[optimistx]

Input elements outside of forms dont conform to HTML standards, AFAIK.

And how are you going to "receive" input and "store" it wherever
without a program on the server side?

Cookies reside in the user's computer with the browser. They are stored
there,
when the js-code is executed. There needs to be no programmatic
handling at the server. (but perhaps cookies make some trips back and forth
anyhow?)

 

[Gregor Kofler]

optimistx meinte:

Cookies reside in the user's computer with the browser. They are stored
there,
when the js-code is executed. There needs to be no programmatic
handling at the server. (but perhaps cookies make some trips back and forth
anyhow?)

Yes they do. That's why they are. But without server-side scripting they
are relatively useless (and again no security issue for the server).

Gregor

 

[Dr J R Stockton]

Dr J R Stockton wrote:
...

Thanks for the info.

Is it like this:

If the page contains a form, which is set by a post or
get http-request to the server, a malignant user of some defective
browser can fill something in
a form on a page so that server security is at risk even
in the case when the
server does not contain any code from the author to handle the
request ?

It bears no resemblance whatever to that. The words "of a form" may
have deceived you; substitute "in a manner".

The possible breach of security/safety, if actual, could be employed by
the author to attack the reader's machine; or could cause the reader to
inadvertently damage his system.

Again : although it is an undeniable and fix-worthy browser flaw, there
is only a possibility that it could be an exploitable one.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

optimistx meinte:

What's a form good for, without server side scripting (which you don't
have)?

Why do you say that Optimistx, to whom you are responding, does not have
server-side scripting?

Note that an insecurity can be detected by using only a local script in
a local page. ***IF*** I were to write, on a local machine, a page
which in browser X could, merely by executing some script as a result of
selecting some button, read anything it liked from the machine's disc
and write it into, say, an inconspicuous textarea in a form, ***THEN***
you, for example, could put corresponding script on a web page with
client/server interaction and read the hard discs of those who read your
page with browser X.

Quite independently of the submit mechanism, a form is a useful way of
containing a set of controls with a local name-space. For example, if a
form button's onClick is set to "Func(this.form)", then a routine
declared by function Func(F) can address other elements of the form
as properties of F - and the same Func can be used for more than one
form.