As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Is it possible to build dynamic web applications using client side javascript as the pivotal point? I'm not talking about server side javascript (like node), I'm talking about handling most of the site with javascript: templating, form handling etc.
Of course, the short answer is "yes, it is possible". But my main concern is about database data manipulation and security when the database is traditionally located on a server. A clientside javascript driven application should ideally talk almost directly with the database. I know Couchdb allows this, but how to prevent users to submit queries meant to see data they should not be allowed to see? How to handle input validation considering that the main validation should be also client side and so easily forged?
This seems to me very interesting but not really doable, but maybe there are solutions I'm not aware of, or tiny security layers to wrap around some db, or projects I ignore etc.
I'm aware of CouchDb Standalone apps (couchapp) , it's a technology close to what i'm after, but it enforces an open approach that makes it not ideal for every scenario I can think of.
Any suggestion on this topic is welcome.
EDIT: As examples are required, think at the simples blog. I want to show the last five posts in the front page. If someone "hacks" the page in a very simple way, they could retrieve older posts. That's fine. Bu what when I want to insert a new post? If javascript has open access to the database, anyone can also write posts in my blog - I don't want it. Also, anyone can delete my posts or other users comment, a privilege that I want. And what if I want to avoid comments longer than 500 characters and containing bad words? Again, being validation on the client-side, users can bypass it.
First, running code on your clients to directly access the database sounds like trouble; it seems to go against the very idea of information hiding that has been so instrumental in designing more complex systems.
So, I assume most of this is an academic exercise. :)
Most centralized database systems have multiple users or roles themselves; typically, we use a single "user account" per application, and allow the applications to define users in their own way. (This has always bothered me, it always felt like admin vs user roles should also be separated in the database. But I appear to be alone in my opinion. :)
However, you could define an admin role and a user role in your database, GRANT SELECT privileges to your user role, and GRANT SELECT, UPDATE, INSERT privileges to your admin role.
PostgreSQL at least has a predefined PUBLIC that can take the place of user; the following example is copied from http://www.postgresql.org/docs/9.0/static/sql-grant.html :
GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
Correct configuration of the pg_hba.conf file could allow admin users to log in from specific IPs, and user users to log in from everywhere else, so you could restrict UPDATE and INSERT to just specific IPs.
Now the difficulty is in writing a PostgreSQL client library in JavaScript. :) I honestly haven't got a clue if the browser-based JavaScript virtual machines are flexible enough to allow arbitrary sockets communication with a remote host. (Given how WebSockets have been so heartily embraced, I'm guessing JavaScript is very much stuck in the HTTP world.)
Of course, you have to serve your HTML pages to the web browsers somehow, and that means having an HTTP server. You might as well ask that server to sit between the clients and the database. And you might as well do some processing tasks on the server to avoid sending redundant / unnecessary data to clients as well... which is exactly how we have the situation we have today. :)
Yes it's possible to have a web application which depends heavily on JavaScript; however, most of the time this layer is just additional; not a replacement. Most of the Developers out there think about JavaScript as just a convenience layer which makes transactions "easier" for the end-user, and you could say that that's the best approach security-wise. JavaScript as a "definitive" tool, to sanitize malleable data to a trusted database is just not efficient; unless you want to treat all your data as insecure, and sanitize it every single time you display it and deal with it from JavaScript itself.
Fancy animations, AJAX, validations, calculations, are usually there only for convinience, under the thinking that sometimes it's better to use the client processor rather than the server's. And of course, the fact that making things "faster" has been something everyone has been wanting to achieve since the 56k internet connection.
Security wise, having the security logic without any extra layer of protection available to the end user is just insane. Think about JavaScript as an Extra hand. What JavaScript can read, the user can read. You wouldn't be storing database credentials, or password hashing keys on there would you?
Specially since JavaScript can be modified in the run with a debugger, and pretty much any obfuscated code can be solved to something readable by a human.
Leaving that insertion and 'secure' data aside, you shouldn't have much trouble fetching publicly available information, if your source is secure.
For the javascript front-end I would recommend Backbone.js, which will give you a solid base on the organization and interaction side:
Backbone supplies structure to
JavaScript-heavy applications by
providing models with key-value
binding and custom events, collections
with a rich API of enumerable
functions, views with declarative
event handling, and connects it all to
your existing application over a
RESTful JSON interface.
The only thing that would be left is having a thin layer that could rest on top of your DB (or even the db itself) to sanitize the data upon insertion and to store / compute sensitive information that can't be exposed under ANY situation to the client.
UPDATE
The Blog Example
The 3 real requirements to do what you want.
Authentication (backend) : this would be needed to access the db, to erase comments, and so on.
Validation & Sanitization (backend) : Limit amount of characters, escape malicious code, ban words.
Sensitive Data Handling (backend) : Using a Hash to for passwords...
Note: You can pretty much bypass the "Validation & Sanitization" by dealing all your data as insecure when you display it; like I mentioned highly inefficient since you would need the client to parse it somehow to make it secure; and it's still highly probable it'll be bypassed. The other two, really require you to have a secure way to interact with your valuable db.
Usually: If your back-end fails, your front-end fails. And vice versa. A XSS can do a heavy amount of damage on a JavaScript ruled site (like Facebook for instance).
It is not possible to talk to the database from the client-side. For security's sake, and validation you do must be done twice. Once on the client-side, once on the server-side.
Anything that you can do on the client-side can be forged by a malicious user. Client-side validation is mainly done as a convenience to the user. It's the server-side validation that provides database security.
Related
hi everyone :) I'm currently a front-end beginner and I'm wondering if I could manage users authorities by JavaScript code alone?
I want to create a simple Student Management System with Log in Features, with admin who have the full authority to manage the students data (add, delete, update)& other users can only log in and read.
it that possible in the Clint-side? or it's server-side only?
If your access control implementation is done only on client-side it means that it will be relatively easy for an attacker (even for beginner one) to get access to the functionality you want to hide:
Since source code of the app is available, hacker can make changes in it and reveal all the hidden things or remove all the checks/condition you implemented.
Moreover, if all the security logic is located in client-side JS, then your back-end is not protected, so hacker may simply make calls to your API and do whatever he needs even without using front-end at all.
In conclusion, such approach is reasonable only for demo projects or proof of concept, but not for the applications available for public.
I searched a lot on the web but couldn't find an answer.
I'm creating a simple tech wiki/forum website and want to simply add a subscription service that would notify a group of people's emails if any updates are made.
Simplified: The user would enter his/her e-mail (no name only e-mail) in a JS, HTML form and that needs to be stored in a (preferred) SQLite .dd database from which the e-mails would be retrieved (manually) to be sent e-mails to.
Note: The database is currently empty with no tables in it.
This question is probably too broad and not appropriate for the StackOverflow since an answer would entail the design of an entire system covering a number of different technologies including Databases, Website Construction, and Email (which itself is a special form of hell IMO for the uninitiated).
I would recommend you first line out exactly what functionality in detail your website will handle (can people make accounts? can arbitrary users make posts/page?) From there, you will need to divide those features into the right applicable technologies/concerns.
If you've haven't already, I would choose a set of technologies and look for tutorials covering the areas of concern. There are about a dime of dozen blog post on various websites covering common features across web applications. If you don't know what to pick, I would just go with what the blog post uses. Admittedly, this is a terrible suggestion, but I am assuming this is just a side project for you to learn and not for a paying client so that approach is fine to a certain degree (if this is for a paying client, well you're on your own).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm concerned about javascript security as client can view and edit code, I know to overcome this we can use ajax calls to run critical process on server. But recently I was going through parse cloud code, a part of it runs on server. I would like to know if that's the answer to javascript security concerns and is it safe?
Is Parse.com server-side Javascript safe?
Server side Javascript is relatively safe. In the case of Parse.com (I am not very familar with their systems) it appears to accept client-side data. Client side data is always unsafe. That being said, you can make it safe by parsing it (pun not intended) to ensure anything potentially dangerous is stripped out before running it.
The safety in this system then, is dependent on how well you write your code.
Is server-side Javascript safe?
Related to the above, server side Javascript CAN be safe, provided it is written in a secure manner. IE, only data is passed and any data that needs to be secure remains on the server and is only updated by the server.
For example if you are updating game score (taken from some parse.com examples) instead of sending the server the score to update, send it the action that triggers the score update and let the server resolve the action and add to the score. This is safe. Sending the score itself is not, as the score can be manipulated by the client.
Is Parse.com client-side Javascript safe?
Absolutely not. The client is in the hands of the enemy - you can never ever ever trust the client not to manipulate their data and/or the code that generates it.
The onus is on you, the developer, to make sure that your data is being handled and processed only by a system that cannot in anyway be manipulated by the client.
So, is parse.com safe?
Echoing everything that I have already said, parse.com is as safe as you make it. It simply depends on how well you engineer your application.
Is server-side Javascript the answer to security concerns?
Server-side anything is inherently more secure then client side. Is it a one stop fix for all security concerns? No. There are still plenty of dangers in bad coding (IE: SQL Injection) or even open ports (IE: Email forwarding through a web server). Thus there are two aspects to this sort of approach, securing the server and securing the code. These are usually divided up to people of an appropriate skill (developers should not be asked to close ports on the servers, for example, unless there is no one else to do it and you have run out of bananas for the trained monkey).
However, not everything can be run on the server. For example, capturing client input and drawing elements to the screen are two things that the client side will just have to accept. This is where it is on you to decide the needs of your system.
Take our example above about posting score to the server via action instead of score number, it is inherently more secure then sending the score, but it is still not totally secure when sending an action because the player could easily spoof the system to send repeated actions.
You COULD develop some logic to see if the action is allowable, or some even crazier logic to decide if the action rate of a player is Human, but then you could just never let anyone report their score to the server and THAT would be the most safe and also result in a not-very-fun-game.
It's always a calculated risk to decide what areas of anything you can and can't secure and what aspect it will have on the application (or Game - I use game because parse.com examples used game) in question.
Further StackOverFlow Related Reading
There are some good notes here about the particular vulnerabilities of Javascript Injection:
Javascript security risks?
This one speaks directly to client-side/server-side validation:
JavaScript: client-side vs. server-side validation
There are some notes here about 'how-to' minify and obfuscate code:
How can I obfuscate (protect) JavaScript?
Regarding obfuscation in Javascript, see here for lots of notes about how unsafe it is (especially in the comments):
Hardest-To-Reverse JavaScript obfuscator
If you are really concerned about your javascript, then you can
1) collect your JS routines in a single JS file and minify it using js compress which will make it hard to read and understand.
2) scramble/obfuscate your JS code using JS scrambler which will make it a little more difficult for the cracker to crack your JS
However, considering the vast array of tools available on the web, in my opinion, JS can be compromised any time by the cracker who has a malicious intent. This can be compensated by imposing strict security protocols on the server side.
Hope it helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm familiar with the term hacking. Although i never will become one of those hackers who scam people or make trouble, i believe it's an essential aspect any person who calls themselves a programmer must be able to do, as it is mainly about problem solving. But how does it work? When those people hack games or websites or the guy who hacked sony, do they use a programming langauge like ANSI C or c++ or assembly. Assuming they use a programming language, would it be possible to use javascript to hack in the same way you'd use any other language to hack. Furthermore, what do you have to do to be able to hack too. I just wanna know how it works, and the theory behind it all.
Hacking is unique every time. Exploiting some types of vulnerability doesn't require any particular language at all. Sometimes you hack whatever's there, in whatever language or form you find it. Sometimes it's necessary to automate part of the process, for example password cracking, for which you can use any language you like.
Cracking a commercial game commonly involves studying its disassembled machine code, figuring out which part does the CD or license check, and surgically replacing a few bytes of the code such that the check is skipped.
Hacking a website commonly involves discovery of some small clumsiness on the part of its developers, which allows viewing of should-be private data, or permits execution of custom code if it does not sanitize data properly. SQL injection is a common flaw when values sent to a database are not properly protected within quotes ("...") and so you can give values which break out of the quotes to execute your own commands. Cross-site scripting is a type of hack that uses JavaScript: If a website blindly takes parameters from the URL or submitted form data and displays them on the page without safely encoding them as text (worryingly common), you can provide a <script> tag for execution on that page. Causing someone to visit such a URL allows execution of scripted actions on their behalf. Code injection is also possible on the server side with PHP (or Perl, or similar), if sloppy code gives access to an eval-like function, or if server misconfiguration allows user-uploaded files to be interpreted by the server as scripts.
Hacking into an operating system or server program remotely may exploit bugs in its handling of network commands. Improper handling of malformed network commands can cause it to bungle user authentication checks or even to directly execute code provided in the network packet, such as via a buffer overflow.
Bugs in web browsers, plugins, and document viewers are similar. What should be safe types of file can be crafted with non-standard or broken values. If the programmer forgot to handle these cases safely they can often be used to escape the normal limits of the file type.
Viruses can also be slipped onto a machine via physical exchange of USB stick or CD or convincing someone to install virus-laden software. Such viruses are often written anew for each purpose (to avoid anti-virus software), but there are some common ones available.
Weak or badly implemented encryption can permit brute-force decoding of encrypted data or passwords. Non-existent encryption can permit wiretapping of data directly. A lack of encryption can also permit unauthenticated commands to be sent to a user or server.
Very obvious passwords, or unchanged default passwords, may allow simple guesswork to get into a system. Some people use the same password everywhere. This give websites the power to simply walk in to a user's email account and then take control of everything associated with it. It also means a password leak on one insecure website may be used to access accounts on many other websites.
And sometimes, "hacking" is social engineering. For example, imagine phoning up a junior employee and pretending to be someone in charge, to trick them into revealing internal information or reset a password. Phishing emails are a common, semi-automated form of social engineering.
Breaking into a system is rarely just one of these steps. It's often a long process of analyzing the system, identifying minor flaws and leveraging them to see if a useful attack vector is exposed, then branching out from that to gain more access.
I've never done it, of course.
There is a sort of "hacking" possible with javascript. You can run javascript from the adressbar. Try typing javascript: alert("hello"); in your address bar while on this website.
This way it it possible to hijack local variables, cookies for instance.
But since javascript runs on the client-side. People would have to use your workstation in order to gain access to your cookies. It is a technique that can be used to alter login data and pretend to be somebody else (if the site had been badly built).
If you really want to learn more about this there are some 'javascript hacking lessons' that can be found here: http://www.hackthissite.org/pages/index/index.php
Side note, there is a difference between hacking and cracking. Reference: http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)
There are many exploits that can use javascript, probably the most well-known is going to be cross-site scripting (XSS).
http://en.wikipedia.org/wiki/Cross-site_scripting
To follow up on Michael's answer, it is good to know the vulnerabilities in software and how people exploit those vulnerabilities in order to protect against them, however hacking is not something you want to be known for.
For a start, you are actually referring to what is known as Cracking, not hacking. This question will surely be closed, however some brief observations ^_^
Cracking comes from a base level understanding of how computer systems are built, hence you don't learn how to crack/hack, you learn about computer engineering in order to reverse-engineer.
A popular platform for hacking is Linux; over windows for example as its open source so experienced programmers can write their own programs. Although experienced hackers can accomplish their goal on any platform.
There are many levels of hacking however, simple website security is worlds apart from hacking in to Sony and facing jail ^_^
You may have some fun on http://www.hackthis.co.uk though
It depends on many things, for example: how the html code is structured, for example, I don't know if you could hack an iframe, but a normal web-page would be relative easy to hack. Another security pitfall programmers usually do is passing sensitive information via url query-string, then you could get those pieces of data and submitting them wherever they are used in the html code.
There could be another details, but I don't figure them out right now.
I'm thinking of implementing my web application in a certain way as an optimization, and I'd like to get people's opinions on whether this is a good idea or not.
Here's the details:
For most of my pages, instead of determining server side whether the user is logged in, and then modifying the page I send based on that, I want to send the same page to everyone, this way I can make use of my reverse caching proxy and for most requests not even have to run any dynamic code at all.
The differences that need to be done for logged in users will be done in javascript. The necessary information to make the changes (what their user name is, their user id, and if they are logged in or not) will be stored in a cookie that can be read by javascript.
I don't need to worry about the users not having javascript because my web app requires javascript to be used anyways.
Only the most popular pages that are accessible to both logged in and logged out users will do this.
What do you guys think? Pros/cons? Is this something that websites commonly do?
Doing it for 100% of your application would be a little problematic, however, it sounds like you are seeking to use something called the Model-View-Presenter pattern:
http://en.wikipedia.org/wiki/Model_View_Presenter
Be wary that, when using javascript, your code is exposed, meaning that any security measure taken is potentially hackable through the browser. Add protection on the server side and you are set.
Also, since you are going to rely heavily on javascript, I really recommend you using Mootools, which is an object-oriented approach to javascript. That way you can keep your code really modular, work around messy implementations using custom and class events, etc.
Major con: If you are determining what content a viewer can access with JavaScript alone, it stands to reason that a malicious user can potentially access premium content with just a little glance at your source code.
I'm not sure what you are optimizing really - you need to fetch the user data anyway, and only the server has that. Do you plan on sending an AJAX request requesting for data and using javascript to format it? you are only saving on output generation which is usually not the bottleneck in web application. Much more often the database / IO (files) / network (HTTP requests) are the bottlenecks.
The major con here is that by moving all output generation to javascript, you will increase substantially the download size and reduce overall responsiveness. Since none of the big sites use this approach, you can be sure it doesn't solve scalability problems.