6

I've been receiving unexpected data from my web app. Can a hacker change values in a javascript function?

If my code is:

my_function('new_item',10,20,30,40);

is it possible that the 'new_item' parameter has been tampered with? What can I do to prevent this?

McGarnagle
  • 101,349
  • 31
  • 229
  • 260
Erick Engelhardt
  • 704
  • 2
  • 10
  • 30
  • 7
    Just open firebug and you change anything you like, on the client side that is! – adeneo Aug 25 '12 at 17:15
  • An advanced user can do anything on the client-side with your code. – Umur Kontacı Aug 25 '12 at 17:17
  • 3
    You haven't told us much about this "hacker". Is the hacker the user of a browser navigating your site? Somebody tapping into a local network? Somebody else? – Pointy Aug 25 '12 at 17:17
  • Where is this code going next? PHP? If you validate with PHP properly the user input, then it doesn't matter what it's done on the client-side - because it can be just about anything. – Ilia Ross Aug 25 '12 at 17:36

2 Answers2

9

Yes, any user can change any JavaScript that you send to their browser - the word "hacker" is overstated, because even a moderately savvy user is fully capable of pulling apart using Firefox's Firebug, or Chrome/Safari's stock document inspector. This is the reason web developers repeat the axiom:

Never trust user input!

Under no circumstances should you trust anything the user sends. Don't insert anything into the database without escaping it, don't trust the login credential unless the session is verifiable. Anything you trust is a vulnerability, and every vulnerability will one day be exploited.

Don't try to protect your JavaScript, that's impossible. Instead, verify everything the user tries to do: if they request a page they aren't allowed to see, don't serve it to the client even if the JavaScript requests it.

Winfield Trail
  • 5,535
  • 2
  • 27
  • 43
  • 2
    "without escaping it" should be "without using placeholders" ^^ But well-said otherwise. –  Aug 25 '12 at 17:24
  • 2
    It depends on his RDBMS. Placeholders are a lot harder to grok if you don't understand client/serverside separation, so I'm operating on KISS principles. ;) +1'd. – Winfield Trail Aug 25 '12 at 17:26
  • 2
    SQL Injection: http://stackoverflow.com/questions/11939226/sql-injections-and-adodb-library-general-php-website-security-with-examples/12123649#12123649 – Ilia Ross Aug 25 '12 at 17:27
-2

There is NOTHING you can do to make sure all your client-side code is secure, there are some methods that you can do to help make it harder, but they don't really help at all as a more-advanced hacker could easily get passed.

For example if you used

<script></script>

Tags to link in your code via other documents. For example, you could, say have 4 scripts. scripts 1,2& 3 link to each other until they get to 4, where the main functions are. This is not going to prevent anything, it is just going to make it harder for beginner "hackers"/tamper-people. - But it's only mostly effective on chrome's javascript console. Firebug does not care about where the scripts are placed on the DOM. Therefore it just proves that instead of spending time trying to HIDE your javascript code or trying to fully protect it (which is impossible), you should spend time on validating things in the back end.

Just remember there's no way to fully prevent the hacker from tampering with your client side-code. It is never wise to trust anything on the client side. PHP can come in really handy for any back-end checks. Also make sure you prevent against SQL injection in PHP. But don't just think your safe because you used mysql_real_escape_string() ether. Read more about that here: SQL injection that gets around mysql_real_escape_string(), I personally recommend PDO for your db code.

Just think of your sever-side code (like PHP) as the main castle's moat. Now think of the client-side code as the wooden fence around that moat. Any soldier can knock that wooden fence down easily, but they'd have to dig into the moat to get to your keep -(they'd have to get passed PHP validation), if the moat was unguarded (no PHP-validation with the variables) then the soldier could dig away with-out no-one looking.

^ Now think of that as how your website is. Are the moat's vulnerable for digging? If so get some guards there (-make sure you've ensured php validation.)

You SHOULD NEVER EVER TRUST ANYTHING when it comes to client-side. There's NEVER a protection available for that wooden fence. Even javascript guards can't protect it.

[I've edited this answer a lot, because at first I was very unclear of what I actually meant.]

Community
  • 1
  • 1
Jordan Richards
  • 532
  • 3
  • 18
  • 2
    And how exactly does the script tags make it harder, and how would you write functions in the document without them? – adeneo Aug 25 '12 at 17:24
  • You mean that I must "validate" all values from post before using them, right? – Erick Engelhardt Aug 25 '12 at 17:25
  • @adeneo, it's just one of those thigns you can do to make it harder for the hacker to FIND your function. For example you could have 3 scripts but the function being on script number 4, which has been linked to gradually by script 1,2 & 3. – Jordan Richards Aug 25 '12 at 17:29
  • 2
    @JordanRichards What you are trying to pull off there is called security by obscurity, and history shows that it doesn't pay off :) – fresskoma Aug 25 '12 at 17:30
  • @x3ro, wrong, I am just stating that it's just a quick way to make it __HARDER__ for beginners. – Jordan Richards Aug 25 '12 at 17:34
  • 3
    It really doesn't. Firebug doesn't care about the origin of a script in the DOM. – Winfield Trail Aug 25 '12 at 17:36
  • @sudowned a lot of VERY-beginners don't use firebug, they use the chrome-inspect element technique. (I know because that's what I used to do) However I see your point, and as I stated in my post "But there's no way to fully prevent the hacker from tampering with your client side-code." – Jordan Richards Aug 25 '12 at 17:38
  • Chrome's document inspector is the same. Sources tab has every JS file on the page. – Winfield Trail Aug 25 '12 at 17:45
  • @sudowned, your missing the point here... I'm not saying to use ` – Jordan Richards Aug 25 '12 at 17:59