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

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

JavaScript code security

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

Contents

  JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 13:02 -0700
    Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 13:11 -0700
      Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 17:56 -0700
        Re: JavaScript code security Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 02:44 +0100
          Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 19:06 -0700
            Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-24 09:11 +0200
              Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-24 05:56 -0700
                Re: JavaScript code security Wally W. <ww84wa@aim.com> - 2017-05-29 14:57 -0400
                  Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-30 09:41 +0200
                  Re: JavaScript code security Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-06-23 10:53 +0200
                    Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-06-23 13:38 +0200
              Re: JavaScript code security Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 14:28 +0100
                Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-24 18:07 +0200
          Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-24 06:01 -0700
            Re: JavaScript code security John G Harris <niam@jghnorth.org.uk.invalid> - 2017-05-24 14:19 +0100
              Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-24 10:01 -0700
                Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-24 19:18 +0200
                  Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-24 11:39 -0700
                    Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-24 23:07 +0200
                      Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-24 14:26 -0700
                        Re: JavaScript code security "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-25 16:26 +0200
    Re: JavaScript code security Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-24 01:12 +0200
      Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 17:15 -0700
        Re: JavaScript code security Stefan Weiss <krewecherl@gmail.com> - 2017-05-24 04:14 +0200
          Re: JavaScript code security justaguy <lichunshen84@gmail.com> - 2017-05-23 19:47 -0700
    Re: JavaScript code security Myers <xdaamanx@gmail.com> - 2017-05-29 07:54 -0700
    Re: JavaScript code security Myers <xdaamanx@gmail.com> - 2017-05-29 07:55 -0700

Page 1 of 2  [1] 2  Next page →

#33375 — JavaScript code security

For a web app that is hosted on an AMAZON AWS server, I use JavaScript to prevent duplicate data entry for a key field (a question of "EXACT" match was asked here before), considering the fact that the FORM would involve a large amount of data input I didn't implement server side duplicate data validation but I have code to detect if the user browser's JavaScript is disabled, if so, I would alert the user and not display the data entry form.  However, just now I noticed that there are two duplicate records.  What could possibly caused this issue?  One possibility is that the AWS server has been compromised, thus, such duplicate data could be generated via SQL statement.  Another thing, about a week ago, one of the key files were removed from this same server.

What's your thought?

Thanks.

[toc] | [next] | [standalone]

#33376

On Tuesday, May 23, 2017 at 4:02:08 PM UTC-4, justaguy wrote:
> For a web app that is hosted on an AMAZON AWS server, I use JavaScript to prevent duplicate data entry for a key field (a question of "EXACT" match was asked here before), considering the fact that the FORM would involve a large amount of data input I didn't implement server side duplicate data validation but I have code to detect if the user browser's JavaScript is disabled, if so, I would alert the user and not display the data entry form.  However, just now I noticed that there are two duplicate records.  What could possibly caused this issue?  One possibility is that the AWS server has been compromised, thus, such duplicate data could be generated via SQL statement.  Another thing, about a week ago, one of the key files were removed from this same server.
> 
> What's your thought?
> 
> Thanks.

Is it possible that two individuals started to use the FORM at the same time, thus, it would evade JavaScript code for duplicate record entry?

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

#33380

On Tuesday, May 23, 2017 at 4:12:04 PM UTC-4, justaguy wrote:
> On Tuesday, May 23, 2017 at 4:02:08 PM UTC-4, justaguy wrote:
> > For a web app that is hosted on an AMAZON AWS server, I use JavaScript to prevent duplicate data entry for a key field (a question of "EXACT" match was asked here before), considering the fact that the FORM would involve a large amount of data input I didn't implement server side duplicate data validation but I have code to detect if the user browser's JavaScript is disabled, if so, I would alert the user and not display the data entry form.  However, just now I noticed that there are two duplicate records.  What could possibly caused this issue?  One possibility is that the AWS server has been compromised, thus, such duplicate data could be generated via SQL statement.  Another thing, about a week ago, one of the key files were removed from this same server.
> > 
> > What's your thought?
> > 
> > Thanks.
> 
> Is it possible that two individuals started to use the FORM at the same  >time, thus, it would evade JavaScript code for duplicate record entry?

And I wonder if a sophisticated hacker who's extremely knowledgeable of JavaScript can break the JavaScript code of the page to bypass the JS function to prevent duplicate data entry via one particular field.  Thoughts?

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

#33381

justaguy <lichunshen84@gmail.com> writes:

> On Tuesday, May 23, 2017 at 4:12:04 PM UTC-4, justaguy wrote:
>> On Tuesday, May 23, 2017 at 4:02:08 PM UTC-4, justaguy wrote:
>> > For a web app that is hosted on an AMAZON AWS server, I use
>> > JavaScript to prevent duplicate data entry for a key field (a
>> > question of "EXACT" match was asked here before), considering the
>> > fact that the FORM would involve a large amount of data input I
>> > didn't implement server side duplicate data validation but I have
>> > code to detect if the user browser's JavaScript is disabled, if so,
>> > I would alert the user and not display the data entry form.
>> > However, just now I noticed that there are two duplicate records.
>> > What could possibly caused this issue?  One possibility is that the
>> > AWS server has been compromised, thus, such duplicate data could be
>> > generated via SQL statement.  Another thing, about a week ago, one
>> > of the key files were removed from this same server.
>> > 
>> > What's your thought?
>> > 
>> > Thanks.
>> 
>> Is it possible that two individuals started to use the FORM at the
>> same >time, thus, it would evade JavaScript code for duplicate record
>> entry?
>
> And I wonder if a sophisticated hacker who's extremely knowledgeable
> of JavaScript can break the JavaScript code of the page to bypass the
> JS function to prevent duplicate data entry via one particular field.
> Thoughts?

Certainly.  I'm not sure I'd call is sophisticated but, since it's
programming, it's not the kind of thing that most web users could do.

The bottom line is that client-side scripting can't do any serious
validation.  Use it to improve the user experience, not to protect your
data integrity.

-- 
Ben.

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

#33382

On Tuesday, May 23, 2017 at 9:44:53 PM UTC-4, Ben Bacarisse wrote:
> justaguy writes:
> 
> > On Tuesday, May 23, 2017 at 4:12:04 PM UTC-4, justaguy wrote:
> >> On Tuesday, May 23, 2017 at 4:02:08 PM UTC-4, justaguy wrote:
> >> > For a web app that is hosted on an AMAZON AWS server, I use
> >> > JavaScript to prevent duplicate data entry for a key field (a
> >> > question of "EXACT" match was asked here before), considering the
> >> > fact that the FORM would involve a large amount of data input I
> >> > didn't implement server side duplicate data validation but I have
> >> > code to detect if the user browser's JavaScript is disabled, if so,
> >> > I would alert the user and not display the data entry form.
> >> > However, just now I noticed that there are two duplicate records.
> >> > What could possibly caused this issue?  One possibility is that the
> >> > AWS server has been compromised, thus, such duplicate data could be
> >> > generated via SQL statement.  Another thing, about a week ago, one
> >> > of the key files were removed from this same server.
> >> > 
> >> > What's your thought?
> >> > 
> >> > Thanks.
> >> 
> >> Is it possible that two individuals started to use the FORM at the
> >> same >time, thus, it would evade JavaScript code for duplicate record
> >> entry?
> >
> > And I wonder if a sophisticated hacker who's extremely knowledgeable
> > of JavaScript can break the JavaScript code of the page to bypass the
> > JS function to prevent duplicate data entry via one particular field.
> > Thoughts?
> 
> Certainly.  I'm not sure I'd call is sophisticated but, since it's
> programming, it's not the kind of thing that most web users could do.
> 
> The bottom line is that client-side scripting can't do any serious
> validation.  Use it to improve the user experience, not to protect your
> data integrity.
> 
"Certainly", could you show me an example?

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

#33385

justaguy <lichunshen84@gmail.com> wrote on 24 May 2017 in 
comp.lang.javascript:

>> The bottom line is that client-side scripting can't do any serious
>> validation.  Use it to improve the user experience, not to protect your
>> data integrity.
>> 
> "Certainly", could you show me an example?

Wrong Q.

"An" example of code that "can't do" something is nonsense.

The burden of proof is on your side in providing "an" example 
of code that can.

=====

Only serverside is outside the complexity of what browser is used,
or even what non-browser programme.

Only serverside can know what other users, or the same user in different 
windows, just did.

Only serverside is protected from clentside code mongering.

I can imagine some clever ways clientside code can provide a low level of 
such security, but only with the help of serverside code, like one-time 
values of hidden <input>s.


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

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

#33386

On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
> justaguy  wrote on 24 May 2017 in 
> comp.lang.javascript:
> 
> >> The bottom line is that client-side scripting can't do any serious
> >> validation.  Use it to improve the user experience, not to protect your
> >> data integrity.
> >> 
> > "Certainly", could you show me an example?
> 
> Wrong Q.
> 
> "An" example of code that "can't do" something is nonsense.
> 
> The burden of proof is on your side in providing "an" example 
> of code that can.
> 
> =====
> 
> Only serverside is outside the complexity of what browser is used,
> or even what non-browser programme.
> 
> Only serverside can know what other users, or the same user in different 
> windows, just did.
> 
> Only serverside is protected from clentside code mongering.
> 
> I can imagine some clever ways clientside code can provide a low level of 
> such security, but only with the help of serverside code, like one-time 
> values of hidden <input>s.
> 

All right.  I'm going with the best practice of server side data validation now.  Thanks.

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

#33429

On Wed, 24 May 2017 05:56:37 -0700 (PDT), justaguy wrote:

>On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
>> justaguy  wrote on 24 May 2017 in 
>> comp.lang.javascript:
>> 
>> >> The bottom line is that client-side scripting can't do any serious
>> >> validation.  Use it to improve the user experience, not to protect your
>> >> data integrity.
>> >> 
>> > "Certainly", could you show me an example?
>> 
>> Wrong Q.
>> 
>> "An" example of code that "can't do" something is nonsense.
>> 
>> The burden of proof is on your side in providing "an" example 
>> of code that can.
>> 
>> =====
>> 
>> Only serverside is outside the complexity of what browser is used,
>> or even what non-browser programme.
>> 
>> Only serverside can know what other users, or the same user in different 
>> windows, just did.
>> 
>> Only serverside is protected from clentside code mongering.
>> 
>> I can imagine some clever ways clientside code can provide a low level of 
>> such security, but only with the help of serverside code, like one-time 
>> values of hidden <input>s.
>> 
>
>All right.  I'm going with the best practice of server side data validation now.  Thanks.

Good.

That is where scripting belongs -- not in my browser, especially for
navigation.

Does it cost more server machine cycles to:
1) Run a server-side script, or
2) Spew all the javascript (including multiple browser detection
tests, only one of which is applicable per visitor) to each client
machine?

How much internet bandwidth is wasted through the inefficient sending
of scripts to client machines?

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

#33435

Wally W. <ww84wa@aim.com> wrote on 29 May 2017 in comp.lang.javascript:

> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?

I agree somuch with your implied somuch, Wally W.

Measuring the waist circumference for computing someone's BMI
may not be an inefficient waste.

However, your tautological waisted inefficiency 
is sometimes called distributed computing.

<https://en.wikipedia.org/wiki/Distributed_computing>

<https://en.wikipedia.org/wiki/List_of_distributed_computing_projects>

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

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

#33562

Wally W.  wrote:
^^^^^^^^
Your real name belongs there.

> On Wed, 24 May 2017 05:56:37 -0700 (PDT), justaguy wrote:
>>On Wednesday, May 24, 2017 at 3:11:53 AM UTC-4, Evertjan. wrote:
>>> I can imagine some clever ways clientside code can provide a low level
>>> of such security, but only with the help of serverside code, like
>>> one-time values of hidden <input>s.
>>
>>All right.  I'm going with the best practice of server side data
>>validation now.  Thanks.

JFTR: These approaches are not mutually exclusive.  In fact, the best 
server-side validation framework will also generate adequate client-side 
validation code.
 
> […]
> That is where scripting belongs -- not in my browser, especially for
> navigation.

You are mistaken; at best, you are out of touch.
 
> Does it cost more server machine cycles to:
                    ^^^^^^^^^^^^^^^^^^^^^
> 1) Run a server-side script, or
           ^^^^^^^^^^^^^^^^^^
> 2) Spew all the javascript (including multiple browser detection
> tests, only one of which is applicable per visitor) to each client
> machine?

1).  That was easy :)

Besides, there is no “javascript”.

And although “multiple browser detection tests”, and “browser detection 
tests” in general, do not have to be served by the same server, they are not 
only unnecessary; they are, with few exceptions, *unwise*.

We have discussed this here /ad nauseam/.  You should learn about a topic 
before you comment on it.
 
> How much internet bandwidth is wasted through the inefficient sending
> of scripts to client machines?

Difficult to say.  However, scripts do not *have* to be sent *inefficiently* 
to client machines, and there is also “internet bandwidth […]” and “server 
machine cycles” “wasted” by unnecessary roundtrips to servers.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#33563

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 23 Jun 2017 in 
comp.lang.javascript:

>>>All right.  I'm going with the best practice of server side data
>>>validation now.  Thanks.
> 
> JFTR: These approaches are not mutually exclusive.  In fact, the best 
> server-side validation framework will also generate adequate client-side 
> validation code.

Indeed, using the same [nonexistent] Javascript code both serverside and 
clientside pretty much insures validation goes the same way both before and 
after submission, when we ignore or heed the problem of different renderers. 

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

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

#33389

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> justaguy <lichunshen84@gmail.com> wrote on 24 May 2017 in 
> comp.lang.javascript:
>
>>> The bottom line is that client-side scripting can't do any serious
>>> validation.  Use it to improve the user experience, not to protect your
>>> data integrity.
>>> 
>> "Certainly", could you show me an example?
>
> Wrong Q.
>
> "An" example of code that "can't do" something is nonsense.

You cut too much context.  justaguy quoted "certainly" because I'd
stated that something can certainly be done (circumvent client-side data
validation) and he was asking for an example of that.  The thread seems
to have moved now so no need for one, I think.

<snip>
-- 
Ben.

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

#33390

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 24 May 2017 in 
comp.lang.javascript:

>>> "Certainly", could you show me an example?
>>
>> Wrong Q.
>>
>> "An" example of code that "can't do" something is nonsense.
> 
> You cut too much context.  justaguy quoted "certainly" because I'd
> stated that something can certainly be done (circumvent client-side data
> validation) and he was asking for an example of that.  The thread seems
> to have moved now so no need for one, I think.

Okay, Ben.

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

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

#33387

On Tuesday, May 23, 2017 at 9:44:53 PM UTC-4, Ben Bacarisse wrote:
> justaguy  writes:
> 
> > On Tuesday, May 23, 2017 at 4:12:04 PM UTC-4, justaguy wrote:
> >> On Tuesday, May 23, 2017 at 4:02:08 PM UTC-4, justaguy wrote:
> >> > For a web app that is hosted on an AMAZON AWS server, I use
> >> > JavaScript to prevent duplicate data entry for a key field (a
> >> > question of "EXACT" match was asked here before), considering the
> >> > fact that the FORM would involve a large amount of data input I
> >> > didn't implement server side duplicate data validation but I have
> >> > code to detect if the user browser's JavaScript is disabled, if so,
> >> > I would alert the user and not display the data entry form.
> >> > However, just now I noticed that there are two duplicate records.
> >> > What could possibly caused this issue?  One possibility is that the
> >> > AWS server has been compromised, thus, such duplicate data could be
> >> > generated via SQL statement.  Another thing, about a week ago, one
> >> > of the key files were removed from this same server.
> >> > 
> >> > What's your thought?
> >> > 
> >> > Thanks.
> >> 
> >> Is it possible that two individuals started to use the FORM at the
> >> same >time, thus, it would evade JavaScript code for duplicate record
> >> entry?
> >
> > And I wonder if a sophisticated hacker who's extremely knowledgeable
> > of JavaScript can break the JavaScript code of the page to bypass the
> > JS function to prevent duplicate data entry via one particular field.
> > Thoughts?
> 
> Certainly.  I'm not sure I'd call is sophisticated but, since it's
> programming, it's not the kind of thing that most web users could do.
> 
> The bottom line is that client-side scripting can't do any serious
> validation.  Use it to improve the user experience, not to protect your
> data integrity.
> 
> -- 
> Ben.

On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records.  Though 99% of users would not do that but the 1% asshole could cause problem.

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

#33388

On Wed, 24 May 2017 06:01:06 -0700 (PDT), justaguy
<lichunshen84@gmail.com> wrote:

  <snip>
>On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records.  Though 99% of users would not do that but the 1% asshole could cause problem.

And a third thought : What's to stop a hacker writing his own web page
that sends all sorts of naughty submit data to your server ?

  John

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

#33392

On Wednesday, May 24, 2017 at 9:19:53 AM UTC-4, John G Harris wrote:
> On Wed, 24 May 2017 06:01:06 -0700 (PDT), justaguy
>  wrote:
> 
>   <snip>
> >On a second thought, I realized it's easy to avoid client side data duplication validation by opening up two tabs for the same form, copy/paste identical data to the two screens and then hit submit for both, without server side data validation, now we would have two identical records.  Though 99% of users would not do that but the 1% asshole could cause problem.
> 
> And a third thought : What's to stop a hacker writing his own web page
> that sends all sorts of naughty submit data to your server ?
> 
>   John

Good thought.  So, a hacker sees the FORM's action line and sends naughty submit data to it, there we go, we got a serious problem.  I vaguely recall a technique to prevent such hacking?  That's the name of it?  Thanks.

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

#33394

justaguy <lichunshen84@gmail.com> wrote on 24 May 2017 in
comp.lang.javascript: 

>  I vaguely recall a technique to prevent such hacking?

>  That's

"What's" ?

> the name of it?  Thanks. 

Using your intelligence.

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

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

#33397

On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
> justaguy  wrote on 24 May 2017 in
> comp.lang.javascript: 
> 
> >  I vaguely recall a technique to prevent such hacking?
> 
> >  That's
> 
> "What's" ?
> 
> > the name of it?  Thanks. 
> 
> Using your intelligence.
> 

To prevent cross domain (server) form posting, one method seems to find the header info of the http request to determine where the request comes from and if it's not from the same domain/server then reject the FORM posting.

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

#33398

justaguy <lichunshen84@gmail.com> wrote on 24 May 2017 in
comp.lang.javascript: 

> On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
>> justaguy  wrote on 24 May 2017 in
>> comp.lang.javascript: 
>> 
>> >  I vaguely recall a technique to prevent such hacking?
>> 
>> >  That's
>> 
>> "What's" ?
>> 
>> > the name of it?  Thanks. 
>> 
>> Using your intelligence.
>> 
> 
> To prevent cross domain (server) form posting, one method seems to find
> the header info of the http request to determine where the request comes
> from and if it's not from the same domain/server then reject the FORM
> posting. 

The posting is not froom another server, but from the client,
and the header can be manipulated.

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

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

#33401

On Wednesday, May 24, 2017 at 5:08:13 PM UTC-4, Evertjan. wrote:
> justaguy  wrote on 24 May 2017 in
> comp.lang.javascript: 
> 
> > On Wednesday, May 24, 2017 at 1:18:53 PM UTC-4, Evertjan. wrote:
> >> justaguy  wrote on 24 May 2017 in
> >> comp.lang.javascript: 
> >> 
> >> >  I vaguely recall a technique to prevent such hacking?
> >> 
> >> >  That's
> >> 
> >> "What's" ?
> >> 
> >> > the name of it?  Thanks. 
> >> 
> >> Using your intelligence.
> >> 
> > 
> > To prevent cross domain (server) form posting, one method seems to find
> > the header info of the http request to determine where the request comes
> > from and if it's not from the same domain/server then reject the FORM
> > posting. 
> 
> The posting is not froom another server, but from the client,
> and the header can be manipulated.
> 

I was referring to the posting from a web browser (a user agent) on another server, but if it were from the same server (say, I'm the owner of this server), then if another party is able to add file to or change any file on this server that would mean my server has been compromised.  About "the header can be manipulated", then, this technique of knowing where the FORM request comes from wouldn't be effective neither.  That's what you're saying, correct?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web