11

Right now I'm developing a web application and it uses a lot of JavaScript functions so I'm putting all of them in different JS files to access from the HTML, but the functions are "easy readable" so the atacker knows what is going on with the application.

My question is, Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ? If this is true, is there a good solution for this?

I know that I can minify the JavaScript but anyway this will only make the hacker angry...

NathanWay
  • 559
  • 7
  • 14
  • 1
    Dup of http://security.stackexchange.com/q/30928/971. See also http://security.stackexchange.com/q/3174/971 and http://security.stackexchange.com/q/35828/971. – D.W. Apr 06 '15 at 03:07

3 Answers3

35

To state it more directly:

Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ?

No, it is not inherently dangerous for an attacker to see JS and CSS. After all, the attacker or any other client must be able to see these files in order for the application to work at all!

It is your job to design your application so that an attacker who has complete access to the HTML, CSS, and Javascript code still will not be able to execute an attack (whether an attack on the server, or a "client-side" exploit like cross-site request forgery). Easier said than done, of course, but that is the goal.

Actually, good security would mean designing your app so that an attacker who has complete (read-only) access to the HTML, CSS, JS, the server-side scripts, the web server's source code, and the system's configuration still could not pull off an attack. Attackers can, in general, get access to all these things. But in practice, you can take measures to hide the server-side configuration and source code, and it will slow down someone who is not sufficiently determined. You cannot hide the HTML/CSS/JS and still expect the web application to work.

David Z
  • 805
  • 7
  • 15
  • Other thing. Does AJAX compromise the server ? – NathanWay Apr 05 '15 at 06:20
  • 13
    AJAX is a method of sending HTTP requests to the server without the browser having to reload the page. That is all. So if sending HTTP requests to the server is able to compromise the server, then yes, AJAX can compromise the server - but the same thing could be done without AJAX. – David Z Apr 05 '15 at 07:50
  • 3
    A way to think of this during application design is "place very limited trust on data from the client". The server should always do security validation of *any* request it gets. Client-side validation and graceful error handling is nice UX, nothing more. In fact, step 1 of probing/attacking a web app is most likely not to look at source, but to open dev tools (press F12) and watch the network tab, or even just play with the URL -- eg: will it load `changepassword?userid=1` even if I shouldn't have access to that user? – gregmac Apr 06 '15 at 06:47
18

If the attacker can actually do something malicious just by casually browsing the contents of the files served to them, then you have bigger problems than just easily readable files.

In my opinion, you should have something stronger than just security by obscurity. If you do want to make your js harder to read, you can try minfying and obscuring it, though.

Cyrus Roshan
  • 521
  • 3
  • 8
0

Depends on how you handle ajax requests. If you have an ajax fuction which manipulates the database and it is programmed to do "anything that anyone says to it" then it is a security hole, because anyone can tell an ajax function to do anything! it's your duty to check who gives the order or if the order is valid. obfuscating the code doesn't solve anything. a person can still know what button calls which function. an attacker can EASILY find handled events for a delete or update button.

also, your question is flawed because you can't hide javascript in your web application. It simply isn't your choice. Anyone who visits your page has access to all linked javascript files.

Uğur Gümüşhan
  • 121
  • 6
  • 2
    At that point, this isn't a JavaScript problem. In fact, it's far easier just to look at network requests and reverse engineer from there than it is to dig through someone's spaghetti code. – Brad Apr 05 '15 at 16:57