Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 17
  1. #1
    Regular Coder
    Join Date
    Mar 2012
    Posts
    168
    Thanks
    5
    Thanked 11 Times in 11 Posts

    Using JS for security?

    I'm reading up on JS in one of my free-time-read text books. The author is suggesting we use JS to validate form input for security reasons. Now, I'm a beginner but I wanted to cast my prior beliefs out there before I start adapting new ideas. I understand the importance of validating forms. I understand how JS can be useful for validating forms. But shouldn't JS just validate for the user experience? Example: Checks if username is available before user has to refill in the entire form again. I mean, if we use JS for our sole security, can't anyone just turn JS off and get into the system?

    Basically, would you ever use JS for something that NEEDS to work? Maybe not as important as security but something else. Or is it a good idea to only use JS to enhance a website?

    Thoughts?
    Last edited by KULP; 11-20-2012 at 06:41 AM.

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,901
    Thanks
    79
    Thanked 4,423 Times in 4,388 Posts
    You may be a beginner but your instincts are one heluva lot better than that idiot author.

    NEVER NEVER NEVER rely upon JS validation for security.

    As you said, it's great to use it to enhance the user experience, but your REAL validation MUST always be done with server-side code, be it ASP or JSP or PHP or whatever.

    I would definitely cross that author off your Christmas list. Or maybe make sure he gets nothing but a lump of especially dirty coal.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,901
    Thanks
    79
    Thanked 4,423 Times in 4,388 Posts
    p.s.: The *true* hackers don't even USE a browser. They just find a convenient login <form> and then clone the HTTP POST it uses and stuff in anything they want via high-speed non-browser coding to attempt to break your site every few milliseconds.

    There's not even a question about "turning off JavaScript" because their spoofing program doesn't even know what JavaScript is.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #4
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    client side javascript can provide modest security enhancements to an existing form interface, mostly owing to human factors.

    one example would be strict per-field validation that would notice a password being typed in a last name field, which could prevent that password from being shown on-screen in an html error page.

    you can also hash passwords client-side so that your DB never stores someone's password. This is good for security because a compromise of your site won't reveal your user's passwords. This is beneficial because lazy users likely use that same password on other sites, some of which might be very important to them.

    you can use HTML5 for validation instead of JS or to assist JS and provide guidance to users with javascript disabled.

    if you use a backend server, and you are using eval() or saving data in a DB on that server, you need to validate the input no matter where it comes from, unless it's from a trusted client. Even then it's not a bad idea to validate so that you can return friendlier error messages than mysql...

    finally, js might make your app WAY more secure if you get rid of the backend completely. The server has lost a lot of political power over the last five years. Many common/basic server-side tasks can be replaced by newer client technologies like CORS, localStorage, dataURLs, <a download='file.txt'>, postMessage(), webIntents, webRTC, indexDB, and many more.

    the concept of "logging in" more or less still implies a server.
    however, social-sign-in APIs like FB, twitter, gmail, etc CAN be used solely from JS.

    hmm. web services are like server-side code that you don't have to write, patch, and upgrade. this pattern is long-standing. did gmail/yahoo/facebook reduce the number of pop3 servers running world-wide? you betcha. does anyone miss eudora?

    now that i think about it, we might be entering the last 5 years of server-focused web-development, yay!
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #5
    Regular Coder
    Join Date
    Mar 2012
    Posts
    168
    Thanks
    5
    Thanked 11 Times in 11 Posts
    Quote Originally Posted by rnd me View Post
    client side javascript can provide modest security enhancements to an existing form interface, mostly owing to human factors.

    one example would be strict per-field validation that would notice a password being typed in a last name field, which could prevent that password from being shown on-screen in an html error page.

    you can also hash passwords client-side so that your DB never stores someone's password. This is good for security because a compromise of your site won't reveal your user's passwords. This is beneficial because lazy users likely use that same password on other sites, some of which might be very important to them.

    you can use HTML5 for validation instead of JS or to assist JS and provide guidance to users with javascript disabled.

    if you use a backend server, and you are using eval() or saving data in a DB on that server, you need to validate the input no matter where it comes from, unless it's from a trusted client. Even then it's not a bad idea to validate so that you can return friendlier error messages than mysql...

    finally, js might make your app WAY more secure if you get rid of the backend completely. The server has lost a lot of political power over the last five years. Many common/basic server-side tasks can be replaced by newer client technologies like CORS, localStorage, dataURLs, <a download='file.txt'>, postMessage(), webIntents, webRTC, indexDB, and many more.

    the concept of "logging in" more or less still implies a server.
    however, social-sign-in APIs like FB, twitter, gmail, etc CAN be used solely from JS.

    hmm. web services are like server-side code that you don't have to write, patch, and upgrade. this pattern is long-standing. did gmail/yahoo/facebook reduce the number of pop3 servers running world-wide? you betcha. does anyone miss eudora?

    now that i think about it, we might be entering the last 5 years of server-focused web-development, yay!
    Now what would happen if the user disabled their JS? Either your web app is no longer on option for them (if entirely js) or they can easily break in. Right?

    Quote Originally Posted by Old Pedant View Post
    You may be a beginner but your instincts are one heluva lot better than that idiot author.

    NEVER NEVER NEVER rely upon JS validation for security.

    As you said, it's great to use it to enhance the user experience, but your REAL validation MUST always be done with server-side code, be it ASP or JSP or PHP or whatever.

    I would definitely cross that author off your Christmas list. Or maybe make sure he gets nothing but a lump of especially dirty coal.
    Yeah I haven't been impressed. It's a textbook for a class I may be taking next semester, just getting a 'little' ahead (reading the whole book before the first day). He also taught html by using tables in the first couple chapters. He did specify that he will explain later why not to use tables but still I don't understand why one would teach an old way and not just dive in to the right way. Teaching bad habits is never a good idea 'in my book'.

  • #6
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by KULP View Post
    Yeah I haven't been impressed. It's a textbook for a class I may be taking next semester, just getting a 'little' ahead (reading the whole book before the first day). He also taught html by using tables in the first couple chapters. He did specify that he will explain later why not to use tables but still I don't understand why one would teach an old way and not just dive in to the right way. Teaching bad habits is never a good idea 'in my book'.
    If the HTML in the first few chapters uses HTML tables then the JavaScript in the book is probably prehistoric. JavaScript now is almost a totally different language from what it was in the days of Netscape 2 through 4.

    Now if the HTML in the first few chapters used CSS tables then it would be reasonably modern in its approach (but then there wouldn't be any reason for explaining why using tables is a bad idea because CSS tables are intended for doing page layouts of non-tabular data).
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #7
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by KULP View Post
    Now what would happen if the user disabled their JS? Either your web app is no longer on option for them (if entirely js) or they can easily break in. Right?
    their option is to re-enable it; you can't drive a car if you disconnect the battery.

    it's a moot point anyway; nobody disables javscript.

    again, javascript has little to do with the major security problems out there.
    in fact, 90/100 security lapses result from poor server behavior like failing to sanitize redistributed input, allowing sql injections to leak unhashed or weakly hashed (md5) passwords, and using basic authentication over http. 9 of the the remaining ten are human factor lapses like pharming, call from "nick down in IT who needs you to confirm your password", and post-it note passwords.

    on the other hand, if your app is comprised of html/css/js/and webservice APIs, your attack profile is only through the APIs, which presumably are well-managed, tested, and maintained by the big guns that operate them for millions of customers.
    Last edited by rnd me; 11-20-2012 at 07:36 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #8
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by rnd me View Post
    it's a moot point anyway; nobody disables javscript.
    Depending on which statistics you believe somewhere between 5% and 10% of web users do not have JavaScript enabled.

    It is a moot point though regarding JavaScript and security. Any security measures implemented in JavaScript can be easily bypassed by turning JavaScript off.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #9
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,901
    Thanks
    79
    Thanked 4,423 Times in 4,388 Posts
    Quote Originally Posted by KULP View Post
    Yeah I haven't been impressed. It's a textbook for a class I may be taking next semester, just getting a 'little' ahead (reading the whole book before the first day). He also taught html by using tables in the first couple chapters. He did specify that he will explain later why not to use tables but still I don't understand why one would teach an old way and not just dive in to the right way. Teaching bad habits is never a good idea 'in my book'.
    Sounds to me like you should now question the judgment of the instructor who would choose that book as the class textbook!

    If the instructor doesn't know how bad the book is, then maybe he/she shouldn't be teaching the subject.

    On the other hand, if the instructor acknowledges the faults of the book and says he/she will correct those faults in class, then indeed he/she might be worth studying under.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #10
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by felgall View Post
    Depending on which statistics you believe somewhere between 5% and 10% of web users do not have JavaScript enabled.

    It is a moot point though regarding JavaScript and security. Any security measures implemented in JavaScript can be easily bypassed by turning JavaScript off.
    1. can you provide a link to anyone reporting >2% ? the public-facing server at work got over 1 million hits last year. after eliminating bots and google pre-fetches, i determined that there were 40 more requests to "/css/index.css" than "/js/jquery.js". i checked the number three times.

    so maybe 40 out of a million is not "one in a million", but it's closer to "nobody" than a constituency that demands development consideration.


    2. any measures taken in js are disabled by disabling js. if you use js for security, the developer needs to make sure the app won't work at all without it.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #11
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,901
    Thanks
    79
    Thanked 4,423 Times in 4,388 Posts
    Quote Originally Posted by rnd me View Post
    2. any measures taken in js are disabled by disabling js. if you use js for security, the developer needs to make sure the app won't work at all without it.
    That sounds like a great idea, but I wonder if it wouldn't be a lot harder to implement than simply doing good server-side security (in addition to whatever JS security you use).

    Seems to me that implementing "the app won't work with JS disabled" means you also have to be sure that your site isn't being hit by some hacker bot that either doesn't care about JS or simulates JS working to at least some degree.

    I am hard pressed to figure out such an implementation.

    A naive one would be to not have a SUBMIT button for your <form> and only enable submit via a JavaScript function call of some kind. But clearly a hacker bot would never actually "push" a submit button anyway.

    So can you tell me what kind of JS code you would be thinking of that would satisfy "the app won't work with JS disabled"? Hacker-proof?
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #12
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by rnd me View Post
    2. any measures taken in js are disabled by disabling js. if you use js for security, the developer needs to make sure the app won't work at all without it.
    The other thing is that user JavaScript attached to the web browser can rewrite and author JavaScript attached to the web page.

    So you provide a web page that doesn't work without JavaScript that applies security measures in the JavaScript.

    I attach some JavaScript to my browser that rewrites your JavaScript so that whatever I want will be accepted as passing the JavaScript security.

    The supposed security your JavaScript included has then been successfully ignored.

    You need to remember that the browser owner has full control of the CSS and JavaScript run in their browser - the only thing you supply that you can be certain that they will not override is the content.

    Any security measures MUST be implemented on the server or your visitor can simply override it.

    It is of course a different matter if it is the browser OWNER implementing security that prevents JavaScript in web pages from being able to do things they don't want to allow - then they can simply attach a script to their browser that automatically overwrites and scripts in the page after the page has loaded.
    Last edited by felgall; 11-21-2012 at 01:07 AM.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #13
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by Old Pedant View Post
    That sounds like a great idea, but I wonder if it wouldn't be a lot harder to implement than simply doing good server-side security (in addition to whatever JS security you use).

    Seems to me that implementing "the app won't work with JS disabled" means you also have to be sure that your site isn't being hit by some hacker bot that either doesn't care about JS or simulates JS working to at least some degree.

    I am hard pressed to figure out such an implementation.

    So can you tell me what kind of JS code you would be thinking of that would satisfy "the app won't work with JS disabled"? Hacker-proof?
    sure, although my point could have been clearer. If you have a server-based app that you can sleep at night trusting, then by all mean, add JS to improve the UX. do it yesterday.

    if you already have a server-based app, but it has security issues, JS can actually help you out there as well.

    importantly, don't build something from scratch that RELIES on BOTH JS AND a server; it's very easy to introduce security holes without years of experience preventing them in such designs.

    the bigger and perhaps more novel point i wanted make is that the safest apps are those that only use javascript. your liability in such cases is greatly diminished. even if you get sued because of a security issue, you will have someone else to sue, likely someone with more money than you. In the USA at least, contractual agreements, like a TOS for example, cannot waive liability due to negligence.

    as far as what i was referring to, CAPTHA come right to mind.
    but my goal is to basically have JS be the one typing in the CAPTHA: validate that there is JS, and deal with it only. this can be as simple and intuitive and feeding ajax pre-set url bases from an external script. since the api URLs aren't linked/sniff-able in html, like a <form action is, your drive-by profile for spammers and hackers goes way down.


    we used to get hit with tons of spam on the comment system at work. I added some javascript, unspecified, and low and behold, 90% of it disappeared overnight while simultaneously improving the UX for humans that use the form. We still get low-wage cut-n-pasters, but what can ya do about that?


    consider danml.com/slim/ . it won't work at all without javascript. the only server it uses is google's for the closure routine. if i did the processing on the back-end, i open myself up to DOS, and XSS, and considering the location.hash/window.name macros i have in place, that would be robotic-ally very bad. as is, i don't know what a hacker's robot would want with code it can't run...


    consider danml.com/sandbox/. for me, and only for me, the "load" drop down is synced on all my desktops. it's got dozens of items right now. go ahead and dig through the source; you won't find the smoking gun that enables this. It's added via mini's $ONLOAD API. a simple link with code in location.hash can add routines to $ONLOAD, which will then run, unsurprisingly, the the page loads.


    that's an example of digital security at it's absolute strongest: physical.
    since the sync code does not exist on the public-ally view-able source, it is not possible to intercept my personal snippets. no brute-force, no session spoofing, no sql password leeks, nada. looking from afar, a hacker cannot determine where to start; the sync server isn't even on danml.com...

    what about examples that don't directly relate to me?


    i admit, most web developer approach app development like it's 1997; beginning the process by focusing on DBs and which "P" of LAMP to use. im not kidding either, there are folks who i tell about an idea, and the first thing they say is something about node.js or some new php framework they just heard about. Ive become used to laughing and crying simultaneously. There was an honest debate about using JS 5 years ago, but that ship has long since sailed...


    meebo did the thick-client thing years ago, and i don't recall them every getting hacked.

    there are innumerable online multi-player games that use flash, which is another client model, which uses http/utp to phone home to a server, just like js. those games won't work without flash, just like html5 apps won't work without javascript. That makes it a lot harder to cheat in the game...






    finally,

    you can use firebase, pusher, gdata, yahoo pipes, blogger, YQL, paypal, and social signins to:
    -allow user registration (social sign-in APIs)
    -store user-generated data (firebase/gdata/pusher)
    -allow opt-in instant communication between individual clients (firebase/pusher)
    -publish sanitized user-generated content to the public RSS feeds (pipes, blogger, gdata, YQL)
    -collect real money from real people to continue using your app (paypal+firebase)


    i won't even get into the now-available turnkey PaaS bundles or SaaS options, but expect huge growth in that sector in the next 5 years.

    it won't belong before there are legit web-app millionaires who can't tell you what "LAMP" stands for.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #14
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,073
    Thanks
    11
    Thanked 98 Times in 96 Posts
    clientside technologies are as safe as the client is.. thats ma and pa's unpatched XP with SpeedUpMyPC-Pro and driver-miracle-cure installed + millions of 'macs cant get a virus' fondleslab users.

    thats several million potential issues on the client and ... 1 on the server.

    I had once to (legitimately BTW (developer AWOL)) decompile a flash app that ran on the desktop as an update client to get some keys off it .... and got all the API calls that OK, we had already sniffed since they were not SSL but you get my point.

    ...........

    linkedin, yahoo, serious players, millions of passwords exposed, there is a bigger list if you really need to search for it, they would not of course been web-based attacks but thats actually the point.

    paypal leaks data faster than my pond, and charges far more than my merchant provider and is as likely to suspend my account (and funds) immediately, indefinitely if a grumpy client gets out of the wrong side of the bed.

    all of the above are out of my control, I don't like that.

    .........

    And the one and only reason we are not all using FrontPage as we speak is down to LAMPish stacks, I think they are healthier than you think ? and regardless all the technologies you mention end up talking to a database on a server somewhere (or more likely these days manywhere) so still the security stops there.

    I see what you are saying and mostly get where you are coming from but I don't think the future is as clear-cut as you suggest?
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #15
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by firepages View Post
    And the one and only reason we are not all using FrontPage as we speak is down to LAMPish stacks, I think they are healthier than you think ? and regardless all the technologies you mention end up talking to a database on a server somewhere (or more likely these days manywhere) so still the security stops there.

    I see what you are saying and mostly get where you are coming from but I don't think the future is as clear-cut as you suggest?
    perhaps; we tend to mildly overestimate the progress we make in two years, but we severely underestimate the progress we make in ten years.

    i trust the big guns who sell services and PaaSs; the invisible hand slaps them in the face when they screw up. is the third-party market a utopia? no, it's in its infancy/toddler years. we have a few growing pains left. that's not to say we don't start saving for college now.

    if you are reading this, then you are smart and safe and cool. but i see a lot of poorly configured servers out there. i read somewhere that only 1/3 attacks are even noticed. scary stuff, but if the site/app still works 9-5 and nobody complains, often nobody looks...

    i am not from a computer science background, so i don't judge tech on it's merits, i judge it on it's risks, rewards, uptakes, and universality. Under these metrics, i have found a most appropriate historical analogy:

    100 years ago, electricity was the tech bubble. Every major company had implemented power over the last 10-20 years. This allowed them HUGE output gains, lower labor costs, and faster inventory turn-around.

    There were several forms of electricity being used, and in the US, Edison's DC current motors and generators had the initial upper hand over tesla/westinghouse's AC current.

    DC is poor at traveling long distances without expensive thick copper cables, and there was no "power company"; every company generated it's own electricity. Eventually, as the tech reached consumers, AC's distribution advantages overtook DC's 'easy customization', and municipal distribution started.


    major companies had large investments in generating and consuming DC power, so they did not run to the grid when it first appeared for many familiar reasons.

    All half-way major companies had their own experts at making clean flicker-free DC power.
    Who works for the power grid, low-skill workers?
    Sometimes the grid goes out, which would mean our piano factory is useless at that moment.
    What if the power company decided to jack-up rates overnight?
    What if the power company goes out of business?

    how can we ever trust this centralized monolithic big brother imperfect power company?

    by the early 1930s, nobody but the most specialized of manufacturers generated their own electricity.
    Last edited by rnd me; 11-21-2012 at 03:10 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •