Security risk to eval?

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?

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.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan. wrote:
> 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.
....
There was a typo in my entry, should be: NO sql- files.

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


--
http://www.gregorkofler.com

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

--
http://www.gregorkofler.com

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

On Nov 25, 5:41*am, "optimistx" <optimi...@hotmail.com> wrote:
> 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

On Nov 25, 12:39*pm, JR <groups_j...@yahoo.com.br> wrote:
> On Nov 25, 5:41*am, "optimistx" <optimi...@hotmail.com> wrote:
>
> > 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

In comp.lang.javascript message <4b0cdfa2$0$3885$9b536df3@news.fv.fi>,
Wed, 25 Nov 2009 09:41:27, optimistx <optimistx@hotmail.com> posted:
>
>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.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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 (?).

optimistx meinte:
> 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 ?

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


--
http://www.gregorkofler.com

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.

optimistx schrieb:

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

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?

On 26 Nov, 15:16, Christian Kirsch wrote:
> optimistx schrieb:
>> One can use the input elements inside the form ( or without an
>> actual form)e.g.
<snip>>
> 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.

Christian Kirsch wrote:
> optimistx schrieb:
>
>> 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.
>>
>
> 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?)