PDA

View Full Version : Extjs security issue and vulnerable to hacks ??



punith.mailme
29 Mar 2012, 10:03 AM
Hi Guys,

Off-late we are developing a web application for our client using ExtJs 4.0.7a MVC model.
But we are little new to this whole JS frameworks and don't really understand how it completely works :).

I have certain points i have noticed and need a little help here to resolve those.

1. Based on the logged in user roles and permissions, i have to display various views. i have handled all the roles and permissions on my server side and return a JSON response to my extjs controller to handle weather to display the view or not. But using firebug i can change the response and manipulate it easily to display the restricted view. (this one is of high priority for me, kindly suggest if there is a way to resolve it)


2. I really don't want to show my JS files view model and controller app.js to the user. Read about the builder, minified JS and Javascript Obfuscator to avoid showing my source code. but all the above has a reverse engineering to help the hacker to get to hold my code. :(


3. How easy is it to do a XSS attack on this app.

4. Avoid storing some user manipulated junk data in DB.
i have a scenario in the application where the user will store his preferences in DB and few other places where he will store data. As i have planned now i will be taking the data from the component and save it in DB, I cannot validate if this data is a a valid or not as they are not of any generic type.

Kindly suggest.

Punith

arthurakay
29 Mar 2012, 11:51 AM
The bottom line is that your application is only as secure as your server-side security.

Client-side code, as you've pointed out, can (somewhat) easily be manipulated using Firebug or other debugging tool. There's not a single thing you can do about that.

Search the forums for other topics like this... it's been discussed about 1000 times.

Regarding your points:

1) As I just said, there's no way to prevent the user from altering the code already rendered to the page (or altering the server response). You're only option here is to (a) not load any code the user shouldn't have access to, and (b) make sure that IF the user is smart enough to hack the UI that your server-layer has the necessary security in place.

This isn't the flaw of Sencha's code... it's a gaping security hole in all web applications.

2) Again, you've pointed out that you can minify/obfuscate your code... but if the browser can read it, your users can see it too. Not a thing you can do about it.

3) XSS has nothing to do with the Sencha frameworks. It's a vulnerability that any webpage can have... it's up to your server-level security to prevent bad code from entering your database.

4) More of the same. If the user can manipulate the client-side code at any time, there's nothing stopping them from injecting crap data into the request.

-----

I've said this a million times already (here and similar posts) - the client is inherently insecure. That's not going to change for a really long time, and has nothing to do with ExtJS. You'd have exactly the same problem with jQuery, Dojo, or any other tool.

lucasguaru
29 Jun 2012, 10:40 AM
It's a very nice question.
I'm learing about Secure Development and one thing I figured out is that when you create script to validate the data sent from a user, you protect your application from user doing wrong things.
When you are concerned about doing the validation on the server side, you protect you application from attackers.
A user will not know many things to try to break your code, but I'm sure an attacker will have more knowledge than us developers to find a way to pass throw your security.
Ext is a great think but it's not intended to be secure, because it's impossible from the client side.
What you can do is look for the top 10 vulnerabilities on OWASP and avoid then from the server side.
You can see things like expire the session when logging, validate the ip address for the current session preventing from a session stealing, encode/use black list/use white list for what the user (maybe an attacker) types and so on.
Regards,

Lucas

stimpy
29 Jun 2012, 10:53 AM
/agee with lucas and arthur

bonus points for mentioning OWASP. Required reading .

Assume all client side code is comprimised, Validate ALL input on the server side, Sanitize input and do not allow excution of unsanitized input.

hbopuri
22 Dec 2014, 8:55 AM
How about if you use different libraries/frameworks which are not required to use client side scripting to generate DOM markup, will that increase the scope of security at-least to an extent?