ooops, forgot to mention: The server side components that are providing the data for some web services may not be checking the user's session to make sure that they are logged in. Obviously this is a pre-requisite on which to build any more meaningful security.
----->Nathan .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.: ||:. Nathan Young Cisco.com->Interface Development A: ncy1717 E: [EMAIL PROTECTED] > -----Original Message----- > From: jquery-en@googlegroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Young > -X (natyoung - Artizen at Cisco) > Sent: Tuesday, April 03, 2007 3:30 PM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Web 2.0 is vulnerable to attack > > > Hi. > > I know you asked for code but what you're getting is more > talk. Sorry. > > You can't produce the secret in pure client side JS, you need > the server > to round trip the secret to itself with the cooperation of the JS. > > Also note that as stated before, creating mashups and securing your > service in this way are in simplest form directly opposing priorities. > In other words the simplest way to secure your service from > people using > it in ways that you don't want them to is not to let them use > it at all. > > The simplest thing to check for is the referrer. If the browser > requesting your service reports your own page as a referrer, then you > can send them the response. An attacker can fake the > referrer in their > own browser, but they don't have a session to ride. There's > no way they > can embed a request to your service in their page in such a > way that it > fakes the referrer in the browser of someone who visits their page. > > The way you'd use a secret token is a little more complex, and it > involves the cooperation of client side code. > > An ajax application could increase security by using a secret token in > the following way: > > Assuming the user is logged in and has a session cookie: > > 1. When the server sends a page to the browser, it embeds the secret > token in the page. On the server side, the token is > associated with the > session ID of the visitor > 2. When the client side code in the page does a request (ajax) to the > server, it includes the token as a parameter (and the session as a > cookie automatically) > > There are two kinds of leverage the server has at this point that it > would not have had without the secret. > > First, it can check what kinds of actions are valid for that > token/session combination. For example, the token sent out with an > "edit account details" page might allow for changing the first name of > the person, but not manipulating their orders. > > Second, the server can revoke the token under a variety of conditions. > If the referrer is wrong, if too much time has gone by, if a new page > has been requested, if a request not allowed by that token is > attempted, > etc. > > ----------------->Nathan > > > .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:. > _.:||:._.: > ||:. > > Nathan Young > Cisco.com->Interface Development > A: ncy1717 > E: [EMAIL PROTECTED] > > > -----Original Message----- > > From: jquery-en@googlegroups.com > > [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Sterling > > Sent: Tuesday, April 03, 2007 12:10 PM > > To: jquery-en@googlegroups.com > > Subject: [jQuery] Re: Web 2.0 is vulnerable to attack > > > > >>How about posting some example code that shows an example > > of how secret one time tokens can be created and used within jQuery. > > > > I second that. It would go a long way in educating me on the > > proper way of doing things. > > > > -- > > Benjamin Sterling > > http://www.KenzoMedia.com > > http://www.KenzoHosting.com > > >
