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 2 of 2 — ← Prev page 1 [2]

#33409

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

>> > To prevent cross domain (server) form posting, one method seems to
>> > find the header info of the http request to determine where the
>> > request come 
> s
>> > 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,

A web-browser resides on a user machine, not on a server.

> but if it were from the same server (say, I'm the owner
> of this server),

Impossible, you cannot post "from" a server.

Well, you could using serverside xmlhttp,
so not from a browser, do you mean that?

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

But what has this serverside "file" to do with posting in the sense of 
sending a page request including GET [querystring] or POST [header] content?

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

Indeed, but not as a consequence of your server file story. 



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

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

#33378

Stefan Ram wrote:

> justaguy <lichunshen84@gmail.com> writes:
>>I use JavaScript to prevent duplicate data entry for a key field
> 
>   The rules of parallel programming apply here, because
>   several clients can run in parallel. You might have a kind
>   of race condition. That's what servers and database are
>   made for, i.e., e.g.,
> 
> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> 
>   .

GIGO.

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

#33379

> Stefan Ram wrote:
> 
> > justaguy writes:
> >>I use JavaScript to prevent duplicate data entry for a key field
> > 
> >   The rules of parallel programming apply here, because
> >   several clients can run in parallel. You might have a kind
> >   of race condition. That's what servers and database are
> >   made for, i.e., e.g.,
> > 
> > CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> > 

This approach would generate a db insertion error.  I'd prefer to implement server side duplicate data validation to this method.  But as mentioned earlier I'd prefer not to implement server side validation.

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

#33383

justaguy wrote:
>> Stefan Ram wrote:
>>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> 
> This approach would generate a db insertion error. I'd prefer to
> implement server side duplicate data validation to this method. But as
> mentioned earlier I'd prefer not to implement server side validation.

Of the three methods to prevent duplicate records mentioned in this thread,
only the JavaScript part is optional. If you are at all concerned with
security (and the title of your question suggests that you are), input
validation on the server side is a must. This is not negotiable. The unique
constraint in the database is an added safety net (which you should also
use). It will typically not activate during normal operation, but when it
does, it can save your data integrity.

Relying on client side validation alone is the software equivalent of this:
https://i.imgur.com/bYiIN56.jpg


Given your description, it's impossible to say what caused your duplicate
entries. If I had to guess, I would put my money on

  1) you hit "reload" after a form submit
  2) you made a mistake in your client side checks
  ........
  ........
  42017) somebody hacked your server and decided to mess with you by
         inserting a duplicate record
  ........
  43501) aliens

Problem (1) can be solved by using the POST-Redirect-GET pattern or using
one-time tokens.
Problem (2) can be solved by fixing your code.
Problem (43501) can be solved by sending Jeff Goldblum to the mother ship
and infecting it with a virus.


- stefan

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

#33384

On Tuesday, May 23, 2017 at 10:14:07 PM UTC-4, Stefan Weiss wrote:
> justaguy wrote:
> >> Stefan Ram wrote:
> >>> CREATE UNIQUE INDEX I on TABLE0( FIELD0 );
> > 
> > This approach would generate a db insertion error. I'd prefer to
> > implement server side duplicate data validation to this method. But as
> > mentioned earlier I'd prefer not to implement server side validation.
> 
> Of the three methods to prevent duplicate records mentioned in this thread,
> only the JavaScript part is optional. If you are at all concerned with
> security (and the title of your question suggests that you are), input
> validation on the server side is a must. This is not negotiable. The unique
> constraint in the database is an added safety net (which you should also
> use). It will typically not activate during normal operation, but when it
> does, it can save your data integrity.
> 
> Relying on client side validation alone is the software equivalent of this:
> https://i.imgur.com/bYiIN56.jpg
> 
> 
> Given your description, it's impossible to say what caused your duplicate
> entries. If I had to guess, I would put my money on
> 
>   1) you hit "reload" after a form submit
We can eliminate this one because after form submission it's automatically redirected to another page (eliminating the opportunity of "reload", hence, room for creating duplicate records).

>   2) you made a mistake in your client side checks
This web app been tested on two instances (two servers), the client side check works fine.  Thus, we can eliminate this speculation as well.

>   ........
>   ........
>   42017) somebody hacked your server and decided to mess with you by
>          inserting a duplicate record
This is a possibility.  Since about a week ago, a critical file on the AMAZON AWS server was mysteriously removed. 
 
>   ........
>   43501) aliens
> 

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

#33423

That is great dude but how could we use it in other ways?

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

#33424

That is pretty challenging

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web