Develop Reference

Can we send user info from client-side to the server-side, safely? [duplicate]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.
My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.

Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page.
If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission.
Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.
Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.
What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.

Validation should always be performed server-side - you can never trust client-side validation.
Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.
As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.
Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.

Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.
For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.
Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.
Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.

If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:
User has disabled javascript
An evil user in purpose has removed the javascript in order to exploit the system
With javascript validation you reducing the data traffic between the website and the client.
And of course with server validation you make sure once for all that the data are correct
It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.

Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.

What are the security trends for client side coding in web development [closed]

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
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.

Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.

I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.

Javascript: Can allowing custom javascript within a closed source CMS be bad? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There are a lot of features and abilities of javascript that I am unaware of. I have developed a custom closed source CMS and I was thinking about adding a feature to allow for custom javascript that gets included on each page of their site (but not the backend system itself). I was curious of the risk involved with doing this? The CMS is built using PHP and there is javascript within the backend system of this CMS, but thats pretty much it.
If I allow custom javascript, can this be manipulated to retrieve all the php code, or to cause issues on the server itself?
I own the servers, so I can make any adjustments necessarily for safeguarding the server.
Again, this is purely for information and I appreciate any advice people can give me.
The javascript will be stored in a file and included using php on the page itself. I do have code that blocks anything inside to prevent the use of PHP within the code itself.

Can they steal my closed-source PHP code with JavaScript?
To answer your first question, no, your closed-source PHP code cannot be stolen by a user of your CMS software simply by uploading a JavaScript snippet.
This is because JavaScript runs on the client-side (the web browser).
If JavaScript is able to access your PHP code from the client-side, then they'd be able to access it without JavaScript. That would mean that you've configured something wrong on the web server side, like setting permissions on your files so that anyone can view them.
Is allowing JavaScript to be uploaded by a CMS user a good idea?
You'll get some folks who will scream ABSOLUTELY NOT UNDER ANY CIRCUMSTANCE. These are the same people who say things like:
Using eval() is always evil. It's not always evil, but it's almost always unnecessary.
Using global or $_GLOBALS in PHP is evil. Again, it's only evil if you don't know what you are doing. And again, it's almost always unnecessary.
You should read that as a WARNING. Don't treat this issue lightly, if you are careful, you can do it, but if you are not, it can really bite you in the a**. That's reason enough for most people to stay away from it.
Before you decide for sure if you should or shouldn't allow users of your CMS solution to upload JavaScript snippets, you should ask yourself the following question:
Who will be allowed to upload JavaScript snippets?
If the only people who have access to this feature of uploading JavaScript modules are trusted system administrators, then you should consider it safe. I put that in italics because it's not really safe, but it does, at that point, fall on these trusted users to ensure that they don't upload something malicious.
Maybe you get Mary Neophyte, webmaster(amateur) extraordinaire who decides she wants a cool scriptlet on her CMS front page that displays the current weather in Anchorage, Alaska. She goes to Google, types in "JavaScript weather script", and arrives at Weather Channel. She decides their implementation is just too hard to install. She keeps looking. She arrives at Boris' Weather Script at http:/motherrussia.ru/ilovehackingidiots/weatherscript.html.
This isn't your fault when her CMS starts compromising her end users. She was the trusted administrator who uploaded a malicious script purposefully (though ignorantly). You shouldn't be held responsible for this type of behavior.
Long story short, you should be able to trust the trusted users of your CMS to be responsible enough to know what they are uploading. If they shoot themselves in the foot, that's not on you.
Allowing non-trusted users to upload JavaScript
This absolutely, positively, without a doubt is never something that you should do. It is impossible for you to screen every possible obfuscation that someone could upload.
I'm not even going to get into this further. Don't do it. Period.
Regarding HTML/CSS
Don't assume that malicious code can't make it onto your website via HTML/CSS. While HTML is much easier to sanitize than JavaScript, it can still be exploited to deliver undesired JavaScript to a page.
If you are only allowing trusted users to upload HTML/CSS, then don't worry too much about it. I stress again, It is Mary Neophyte's fault if she uploads Boris' Weather Script to her site. However, don't let Boris himself come to your website and start uploading anything that will get displayed on a web page to anyone but ol' Boris himself.
TL;DR
I'll summarize everything into two rules:
Don't allow untrusted users to upload anything that will be displayed to anyone other than themselves.
Don't let anyone upload anything at all that gets executed server-side.

Allowing custom JavaScript would probably be a very bad idea. That would make your site vulnerable to cross-site scripting attacks and allow it to be a vector for cross-site request forgery attacks against other sites.

Is it possible to hack with javascript? [closed]

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.

Client side javascript driven websites [closed]

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.