Security Issues in Web Applications using Javascripts....

[Mohammed]

guys,

as per rich client interface is concerned....yui-ext tools are the best....so client side implementation can be achieved with no doubt about it.

as per web services is concerned.... i go for MS webservice project development using vb.net. Hence, its just a matter of passing all the calls from client side to webservice which throws the result in xml/json format.

now coming to admin side.....am not sure how to maintain security. Think of any content management system where customers/clients/admins/super admins logs onto the system and manage the content based on their permission settings....how can we achieve this in html/javascript style programming.

what are your suggestion. How can we achieve this especially when smart devs can simply view page source / get javascripts sitting in hosting servers.

am thinking of creating AJAX style admin side application seperately in ASP.NET which looks after security much better. which means two applications, client side using yui tools and admin side using ASP.NET.

I have done tons of wins/web application in Visual Studio. But this is the first commertial web application project being implemented differently for quality purpose.

Thank you in advance.

[BernardChhun]

For those smart devs use this for your javascript: http://dean.edwards.name/packer/
That won't stop them completely but it helps! ;)

[Mohammed]

no bernard,

my biggest concern is the business logic....if its written completely in JS....do you think its safe....plz. kindly correct me if am wrong...

[jon.whitcraft]

no bernard,

my biggest concern is the business logic....if its written completely in JS....do you think its safe....plz. kindly correct me if am wrong...

I consider all JS to be Client Tier and the Business Tier the the Server Side technology (SST) that the AJAX calls to to store the data.

There might be some sort of line there were since the Client Tier is more interactive that it has to contain some of the Business Tier but all processing should be done using an SST.

The best way to do this is have your js app aware of their security level and only have it loads the parts they have access to. My admin that i have for my company is pure PHP on the backend with a majority of the admin tools updated to have the interface based off of Ext. Now people who don't meet the access restrictions for a given section don't get access to it and if they try and get access to it i display an Ext MessageBox saying that you don't have access to this section.

Does that help??

[Mohammed]

to some extent sidhi,

if you can provide me some samples/ weblinks where user logs in...communicating with server serside (either php, vb.net etc...) for authentication.......if successful then he is redirected to admin page / extra tools are provided for him to make changes (think of a read only grid. if logs in, add/delete/update etc... premissions are granted !!! )....

thank you in advance

[dfenwick]

You're confusing what's happening in the client with where data is stored. The application is not entirely written in Javascript. It's a viewport. Parts of the business logic are stored on the client for immediate feedback and validation, but the majority of the work actually occurs at the server. Your Javascript application is just controlling the process flow rather than having the web server do that bidding for you as is done in traditional web applications.

Honestly it's not a whole lot different than providing a traditional web infrastructure. What you're aiming for is to guarantee your session is secure and there is an established and persistent authentication object for all requests. There are a number of ways to accomplish this.

Layer 1 is to secure the wire. This means whatever you do, make sure the user can never get to the website via regular HTTP and always uses HTTPS. It's pretty simple to setup Apache to do this.

Next is the authentication mechanism. The objective here is to generate and cache a session object that is guaranteed to be correct between the web server and the web browser for the duration of that web browser's session or until a session timeout occurs. This can easily be provided in one of two ways: HTTP authentication or HTTP sessions.

The positives of HTTP authentication is that it's standards based and provides transparent authentication after an initial authentication is complete. You get headers for the username, password, and realm for every invocation to the web service after this is completed. This includes invocations with your embedded ajax components. The negatives is that it's not secure, so you absolutely need to push it over HTTPS if you're going to use it. In addition, there's no authorization mechanism built in, so you need to roll your own for authorization levels. And finally, you can't log out if you're using HTTP authentication. Once a user is authenticated, there's no means to unauthenticate them other than closing the browser and starting over.

Session-based authentication provides similar functionality to HTTP authentication, but you need to manage the session information yourself. It does not provide a means to do authorization levels either, requiring you to roll your own authorization levels. The benefit of session-based authentication is that you can log out from a session by removing the session variable at the web server. The disadvantages of using session-based authentication is that you have to figure out a mechanism to store passwords in other than cleartext format. This is because you're not sent the username/password combo in the headers, but instead you get a sessionid for the established session. There are adopted ways to do this out in the web development world, so searching for a web authentication framework will net you some of those methods.

I have 5 authentication mechanisms already written for the mail client I'm writing. My first foray into authentication was working with the raw xmlhttprequest mechanism to use the (often unused) 4th and 5th fields during a request. They provide a username and password for http authentication while using the object. I wrote 2 extensions that provide this, one for basic http authentication and one for digest authentication. I based it off existing code that allows one to use a standard HTML form to submit authentication requests via the xmlhttprequest model. The other 3 mechanisms are all tests I've done to use session-based authentication and authorization, and they appear to all work well. Once I'm authenticated, my ajax components work. If I'm not authenticated, they all nicely fail because my PHP pages all require authentication and authorization before they even do anything.

A basic rule of thumb, provided you're not doing persistent cookie session information, is that until a user establishes a known authentication session with your web server, there are no credentials available with which to guarantee their access. Typically the ONLY place I need to make absolutely certain that authentication has happened is on the server, since that's where all of the data will be housed. The browser is just a window into that data.

From a technical perspective, here's how a session-based authentication would work:

- User starts a brand new browser and connects to your ajax-enabled app. It's important to note that starting a new tab or opening in Internet Explorer will carry over any existing sessions and authentications a user has already provided.
- Your application then posts some type of dialog box requiring a login to the server
- The user enters their username/password into that dialog and clicks the login button
- Your javascript should hook the login button and send an ajax request to whatever login script/service/servlet/whatever is running on the server side
- The server takes the parameters and passes them through whatever authentication system you want to use on the server (mysql, pam, ldap, whatever)
- If the credentials work, the server creates a sessionid storage area for this new sessionid and returns a positive response to the ajax client. Part of the http headers for this response is the sessionid for maintaining session information between the client and the server. In the sessionid storage area on the server, you can store whatever variables you want to store. If you're making multiple calls to a backend that requires the user's credentials to be passed, you can store their credentials in the session storage area on the server. They are then accessed via the sessionid on the server.
- The HTTP stack in the browser maintains the sessionid for each successive invocation to the web server that it's talking to and ONLY for that web server. As long as the browser is running, the sessionid is maintained. Once the browser goes away, the sessionid goes away with it. There are known session hijacking hacks out there, but they can be averted by providing a bit more information within the variables attached to the sessionid on the server
- Each of the successive xmlhttprequest objects that ask for data from the server pass the sessionid with it. In your application on the server, the first thing you do for EVERY invocation is validate that the sessionid is still valid. There are mechanisms in most server application frameworks to provide session expiration by a variety of means. You just need to validate their sessionid with whatever framework you're using. In PHP there's a full API for the session information, for example, and it's extremely simple to use (just add session_start() at the beginning of your PHP page and then use $_SESSION['somevar'] to store and retrieve variables in the session store.

Most of the large application frameworks provide some type of authentication support. Horde, for example, provides authentication and authorization mechisms for its framework. There are many frameworks out there, so you just have to pick one that works for you, or roll your own. I already have my own that I like that I wrote, so I just use it.[/list]

[jon.whitcraft]

to some extent sidhi,

if you can provide me some samples/ weblinks where user logs in...communicating with server serside (either php, vb.net etc...) for authentication.......if successful then he is redirected to admin page / extra tools are provided for him to make changes (think of a read only grid. if logs in, add/delete/update etc... premissions are granted !!! )....

thank you in advance

I just use a normal form to have my users login and it just goes to a php page that processes the login and then reirects them back to a list of link that only who what they have access too. then instead of displaing a given data in tables i use a grid and a layout dialog with a form it it to edit the entire row of data. when the users press the save button it creates a json requset and sents it back to the server to process it.

I use php's built-in session handeling which i'm not sure vb.net has but i very well could be mistaken (I've never used it) to store the their access crendentails so that way i dont have to query for them every time they make a page request.

What I do is instead of using flat html to display my vaules i just use Ext widgets and keep all the db stuff in PHP.

Let me konw if you need more help.

[Wolfgang]

@dfenwick
Really great wrap up :D

@Jack
Can you thake the posting from dfenwick and make it sticky? It certainly is not specific to Ext, but i can imagine it covers answer to questions, new web developer have in terms of authentification.

[Mohammed]

dfenwick and sidhighwind...

many many thanks for brief explaination.... yes, i understood the client -server communication mechanism....

bottom line, both client & admin side can be implemented...its just a matter of security settings we use...using sessions sounds really great !!!.

I have used sessions before in vbscript....i was not dared to use it in CMS (content management system apps). Now, knowing the mechanism, am sure its the same trick with js...

Thank you

[jay@moduscreate.com]

Many security experts feel that any type of client side scripting is a huge no no. Steve gibson is one of those guys that is opposed to javascript.

[JeffHowden]

Many security experts feel that any type of client side scripting is a huge no no. Steve gibson is one of those guys that is opposed to javascript.

No offense to anyone that thinks highly of Steve Gibson, but many (myself included) think he's a complete moron and nutjob.

[HartlepoolLad]

No offense to anyone that thinks highly of Steve Gibson, but many (myself included) think he's a complete moron and nutjob.

Not to mention *boring*! It was so painful sitting listening to those podcasts waiting for him to get to the point :}

[jay@moduscreate.com]

No offense to anyone that thinks highly of Steve Gibson, but many (myself included) think he's a complete moron and nutjob.

I agree. He's one of the world's best ASM programmers alive. All of his apps work and are tiny.

His problem is that he *gets* it, but has issues converting what he knows into real words.

And yes, those podcasts are annoyingly boring when it comes to crap. I wish they would just get to the point.

[jay@moduscreate.com]

Not to mention *boring*! It was so painful sitting listening to those podcasts waiting for him to get to the point :}

Do you have ADD or something? there is a FFW button you know. ;)

[HartlepoolLad]

Do you have ADD or something? there is a FFW button you know. ;)

Cheers for that! :)

I fast forwarded through it but after fast forwarding through the first 20 or 30 minutes, I got bored and gave up :)

[indulgence]

In reply to the original thread... Your backend should validate everything. It should check permissions and validate input before anything happens.

If you are using ASP.NET and since you describe a multi-user environment, then you should have access to the user object making the request... So you can easily validate permissions for the requested action. Validating input can still be tricky -- no matter how good you are at regular expressions... I try to ensure near total security by running all of my input through a regex to remove anything not a letter or number. Users want funky symbols in thier name... tough luck. The more diverse the input you allow - the more at risk your data is to being tampered.

Assuming you construct dynamic SQL queries (which i try my best to avoid...) it becomes hard to prevent sql insertions if you allow the hyphen character to be valid. And it becomes hard to prevent XSS bugs if you allow <> characters. There can still be problems with SQL Insertion and XSS despite those individual characters... but the more restrictive you are in input -- generally, the safer you are.


And Steve Gibson is delusional... By his logic - ASM would be bad because it allows such low-level access to the system and is a historical fav. of virus writers.

[marianomd]

There's something I'm still trying to visualize. Suppose the application doesn't allow Role1 to erase records from some table/grid, but it allows it to users with Role2. And to make it more realistic let's say that roles are stored in the database.

Now, we need to show the "erase" button only to people having Role2.

The first way I can imagine to achieve this is to dynamically generate the js where the grid (for example) is created. Ugly code!

The other way around is sending the intelligence to the browser, and say, for each button, ask to the server if it should be shown or not. The problem would be the large quantity of requests thrown to the server each time the interface loads up.

Maybe a third way could be to ask the server for just one dynamically generated document (json?) with all the ui component id's that should be present. It's not important if this is changed by a malicious user, since we should also check server-side.

Anyone with a cleaner solution?

Thanks,
Mariano

[paulie]

This is interesting. marianomd sums up where I am at with permissions on the client side.

I do my permissions validation server side but I don't want the user to see the 'Create' button on the client side if they do not have permission to create.

My server side is ASP.NET (although this would relate to whichever server side technology you are using) and the user's permissions are stored in an XML string in the Session object.

e.g.


Session("ACCESS_RIGHTS") =
"
<NewDataSet>
<RoleAuthorise>
<Functional_Area>Administration</Functional_Area>
<Facility_Key>user_maintain</Facility_Key>
<description>Maintain Users</description>
<attribute>admin/User_Maintain.aspx</attribute>
<crudval>1111</crudval>
</RoleAuthorise>
</NewDataSet>
"


So far I've come up with getting the crudval for the page and putting it in a hidden field so that is accessible in the client side js.

So Role 1 has a CRUD (Create,Read,Update,Delete) of 1111 in a hidden field on the page and so should see the 'create' button.

Role 2 has a CRUD value of 0100 so will not see the button.

Role 3 has a CRUD value of 0000 or none at all so gets kicked out if they try and access the page ( although I've found it's actually easier to do this one on the server when the page is initially requested )

If I have more complex permissions for the page I also add them in as hidden fields, obfuscating the field names so it is not obvious what it relates to.

Of course this means it is absolutely essential that you also do your server side checking so that if somebody works out the hidden field relates to permissions and spoofs it you catch them out on the server side and return a 'permission denied' error of sorts.

I don't know whether it's better to store this value in a cookie and/or StateManager but so far I've not had much luck finding any useful guides to getting started with these (can anyone point me in the right direction?).

I'll keep at it and post again if I find a more secure method.

I'd also be very interested to hear how others have approached this.

One final thing - this is my first post to the forum. Been using Ext for a couple of months now and I'm blown away at how cool it's making my web apps now so - whilst I have the opportunity - kudos to Jack and many thanks to everyone else in the community for all these helpful forum posts.

[netsuo]

On my part, to show/not show some buttons, controls, i just do like this:

1. i setup a server request before anything loads up in my admin. This request validates user access, gets language strings from the database and load site/admin/user options. All comes back into a json encoded string that's directly readable client side.

2. I check back this json object. If user's logged, i launch the application passing the config/translation object. If not, user simply get a logon panel.

3. in this json object, i have all access-related parameters. So, take for example a menu where you have an item called "menu_manage_users": in my config object, i will then find a variable called "config.menu_manage_users" that is boolean. I just use this value for the "visible" config of my menu button, and that's it !

I know, any user will be able to find the hidden menu item by using "show source", but i check user's access level at EVERY php operation i do, even if the request comes from the EXT part of the application, so i think there's absolutely no problem regarding this way of hiding options.

I really don't know if its a good way to do because i'm a freelance developer, but as of now, i never had any problems :)

[lupin85.luca]

About 2.500 views and only few examples?!
Don't be shy, please share your solutions with us. :)

PS: I haven't built a solution, yet.

[Ephicient]

As a new user to Ext, this topic is our #1 concern while evaluating whether or not to use Ext in our .NET web environment. It would be helpful to see a few more solutions on the topic.

[JeffHowden]

As a new user to Ext, this topic is our #1 concern while evaluating whether or not to use Ext in our .NET web environment. It would be helpful to see a few more solutions on the topic.

Why would whether or not a client-side JS framework provides some sort of security framework be a factor for consideration? Even if you did find a client-side framework that did that for you, you'd still have to implement something on the server.

[paulie]

It would certainly be remiss of any developer to leave security to the client-side alone.

For me the issue is not about where the validation occurs but the best way to send sensitive information such as access rights to the client.

As I see it there are 2 approaches - embed them in hidden fields, or as netsuo points out make another request to the server for them.

Using either approach, however, means that anyone with Firebug can view those values. Since all the rights are telling me is whether a user can see an 'add item' button, for example then this is satisfactory for me since I check on the server side whether the user is indeed allowed to add an item.

If these values are so sensitive that you just can't be doing that then you need to implement a method to encrypt and decrypt key/value pairs that works the same on both server and client.

Here's something I found at Code Project to do this in ASP.NET,

http://www.codeproject.com/csharp/totalsecurity.asp
(http://www.codeproject.com/csharp/totalsecurity.asp)

but if you find that you are in this position you'll probably be working for someone who takes security rather seriously so I suspect copying something from Code Project is also not a suitable solution for you!

[mxu]

one biggest concerns for java applet is the security issue, it loses its place at web client, even it is the most powerful client side tool.

[cobnet]

RE: Only a few examples.

Check out the desktop app created by mxracer. Here he assigns a key to a cookie. The user_id and etc. are checked by this key. So basically no key, no user_id. Enter what you want but you can't get too far.

One additonal example,