I'm developing a simple post application using the React for a front-end and NodeJS + MySQL for back-end. Considering the security I'm wondering where the user input sanitizing should take place - on the client side on the React form component level or rather on the server side in the NodeJS code after the user sends the data? I'm asking especially about the xss attacks , for example to prevent for posting a JS code as a post content/body.
Don't sanitize on the client-side before the data is sent to the server - clients are free to run whatever JavaScript validation code they want (including none), and to POST to your server whatever they want.
A good approach is to sanitize as soon as safely possible. Doing this will result in your database will storing sanitized values, which means that security will not depend on also remembering to sanitize on the client whenever rendering something from the database. There wouldn't be any harm in also sanitizing on the client when rendering, though - it wouldn't add any noticeable overhead, and would provide an extra layer in case you had an endpoint that you mistakenly didn't sanitize before saving to the database.
If you are letting React do the DOM manipulation itself rather than doing it by hand imperatively you don't have a lot to worry about. As long as you stay away from things like dangerouslySetInnerHTML or mutating the DOM by hand.
That being said, there are some things that you can adopt to make it even safer like using DOMPurify when you have no alternative to dangerouslySetInnerHTML.
You could also sanitize user generated content before persisting it to the database to not only prevent XSS but any sort of RCE if you know these values might be consumed by other programs and want to be defensive. But for XSS in React I wouldn't worry too much, It's only through the escape hatches in React that you would manage to get yourselve into an XSS issue.
Here is a good read on the topic https://www.stackhawk.com/blog/react-xss-guide-examples-and-prevention
Related
I'm familiar with using templates in NodeJS like EJS to escape data for an HTML context.
However what would be the recommended way to safely output from an API? Given the intended usage is not known, it couldn't be escaped using HTML encoding.
Since I'm currently basically just doing res.json({}) for the output.
I'm thinking while some fields of incoming data can be validated (like 'email'), other fields that are more vague (like 'description') could contain any of the characters someone might use for XSS. Like < and ;. The options on OWASP seem limited https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html Like this, but it was last updated 7 years ago https://github.com/ESAPI/node-esapi
Is it up to the recipient to handle? So if someone sends "alert(0);" as their description, I allow it through, as that is a valid JSON {"description":"alert(0);"}
If someone wants to send <script>tweet(document.cookie)</script> in a description let them do so. They may have perfectly valid and legitimate reasons to do that. Perhaps they're writing an article about security and this is just an example of an XSS attack.
This isn't a threat to your database but to your web pages.
Security is neither a server-only nor a client-only job. It's a bit of both and the way you mitigate threats depends on the context.
When writing to a database, it's not XSS you have to worry about but things like SQL injection for example.
XSS is a threat for web applications and the way to mitigate that threat is to properly encode and/or escape any user-controlled input before it gets into the DOM.
I would like to create a system where an admin user can set up an HTML-based invoice using EJS, submit it, and then use that EJS to generate invoices.
To do this, I would need them to submit the EJS, store it, and then run it -- server side -- to generate the invoice.
I realise that this is generally a bad idea. At the moment, I am doing my best to put security guidelines in terms of writing the fields with the code in them (only admins can change submit them, etc.). However, I realise that anybody with admin permissions is potentially able to submit a template with malicious code. Questions:
Is EJS at least meant to be safe? (that us, inability to require(), etc.)
What would you do if you absolutely hard to run user- (or admin-) provided code?
Is EJS at least meant to be safe? (that us, inability to require(), etc.)
If you're talking about the ejs template itself, than (generally speaking) it mostly affects security on the browser side.
So just to clarify, you can read an EJS template as string and use the render method from the ejs library to create the rendered html string to be sent to the client. So basically they cant affect the server unless you rely on data from that template that could affect security for you.
What would you do if you absolutely hard to run user- (or admin-) provided code?
If I had to go with this approach I would probably add some validations on the template itself. Maybe even parse the DOM check elements are ok it depends on the task and how the EJS varies.
If security is an important issue for you. You can test the ejs when they upload it with some headless browser to check for anything that is not supposed to be there (unknown ajax requests or script> tags etc)
I have built a game in HTML5 and a web form posts data to a server.
The scores in the game are calculated using Javascript, and the form posts the data to the server.
Won't this architecture be vulnerable to an attack, where the client can be modified, such that it posts rogue values instead of the calculated scores?
How can I prevent this from happening?
To keep things short - you need to do all of your verification server-side. There no problem using client-side scripts to keep things looking good, but you cannot trust anything from the client.
Take Stackoverflow as an example. When you vote it is instantly calculated client-side (to keep things nice and quick) but it is properly validated by the server once submitted.
For example if I attempt to upvote my own answer the server rejects it with the following JSON:
{"Success":false,"Warning":false,"NewScore":0,"Message":"You can't vote for your own post.","Refresh":false}
even though the javascript happily submitted it.
Therefore you also need to calculate your game scores server-side.
Don't trust user inputs, especially trough a form they might perform SQL injection as you send data to your server. (see also How can I prevent SQL injection in PHP?)
Try to verify as much data as possible server side.
Seeing that you also use javascript watch out for javascript injection (http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/Javascript-Injection) as they can inject changes into ur script (e.g. score value)
This is a question involving single page web apps and my question is in bold.
WARNING:
I'm hardly an expert on this subject and please correct me if I'm wrong in part of my understanding of how I think HTTP and WebSockets work.
My understanding of how HTTP restful APIs work is that they are stateless. We use tools like connect.session() to interject some type of state into our apps at a higher level. Since every single request is new, we need a way to re-identify ourself to the server, so we create a unique token that gets sent back and forth.
Connect's session middleware solves this for us in a pretty cool way. Drop it into your middleware stack and you have awesome-sauce sessions attached to each request for your entire application. Sprinkle in some handshaking and you can pass that session info to socket.io fairly easily, even more awesome. Use a RedisStore to hold the info to decouple it from your connect/express app and it's even more awesome. We're talking double rainbow awesome here.
So right now you could in theory have a single page application that doesn't depend on connect/sessions because you don't need more than 1 session (initial handshake) when it comes to dealing with websockets. socket.io already gives you easy access to this sessionId, problem solved.
Instead of this authentication work flow:
Get the email and password from a post request.
Query your DB of choice by email to get their password hash.
Compare the hashes.
Redirect to "OK!" or "NOPE!".
If OK, store the session info and let connect.session() handle the rest for the most part.
It now becomes:
Listen for a login event.
Get the email and password from the event callback.
Query your DB of choice by email and get their password hash.
Compare the hashes.
Emit an "OK!" or "NOPE!" event.
If OK, do some stuff I'm not going to think of right now but the same effect should be possible?
What else do we benefit from by using connect? Here's a list of what I commonly use:
logger for dev mode
favicon
bodyparser
static server
passport (an authentication library that depends on connect/express, similar to what everyauth offers)
The code that loads the initial single page app would handle setting up a static server and favicon. Something like passport might be more tricky to implement but certainly not impossible. Everything else that I listed doesn't matter, you could easily implement your own debug logger for websockets.
Right now is there really anything stopping us from having a single http based index.html file that encapsulates a websocket connection and doesn't depend on connect at all? Would socket.io really be able to make that type of application architecture work without setting up your own HTTP restful API if you wanted a single page app while offering cross brower support through its auto-magical fallbacks?
The only real downside at this point is caching results on the client right? Couldn't you incorporate local storage for that? I think creating indexable/crawlable content pages for search engines wouldn't be THAT big of a deal -- you would basically create a tool that creates static html files from your persistent database right?
Check out Derby and SocketStream.
I think what you're asking for is if it is plausible (using socket.io) to create a website that is a single static page with dynamically changing content.
The answer is "yes", it can work. Several node.js web frameworks already do this although I don't know of any that use socket.io.
I am new to Security of Web apps. I am developing an application in Cakephp and one of my friends told me about the Cross-site request forgery (CSRF) and cross-site scripting (XSS) attacks etc. not sure how many more are there.
I need some help in understanding how to make Cakephp defend my web app against these. we are low budget and we cant hire a security consulant as of now. We are still developing the app and plan to release in by the end of the month. so wanna take care of the initial stuff that can help me stand un hacked ;)
There is not (and cannot be) one tool you can deploy and then never have to think about security again. Deploying ‘anti-XSS’ hacks like CakePHP's Sanitize::clean will get in users' way by blocking valid input, whilst still not necessarily making the app secure. Input filtering hacks are at best an obfuscation measure, not a fix for security holes.
To have a secure web application, you must write a secure web application, from the ground up. That means, primarily, attention to detail when you are putting strings from one context into another. In particular:
any time you write a string to HTML text content or attribute value, HTML-escape it (htmlspecialchars()) to avoid HTML-injection leading to XSS. This isn't just a matter of user input that might contain attacks, it's the correct way to put plain text into HTML.
Where you are using HTML helper methods, they should take care of HTML-escaping of those elements by default (unless you turn off escape); it is very unfortunate that the CakePHP tutorial includes the bad practice of echoing unescaped strings into HTML for text outside of HTML helpers.
any time you create SQL queries with string values, SQL-escape it (with an appropriate function for your database such as mysql_real_escape_string).
If you are using CakePHP's ORM and not writing your own SQL you don't have to worry about this.
avoid using user input (eg file upload names) to name files on the filesystem (generate clean unique IDs instead) or as any part of a system() command.
include the Security component to add a form submission token scheme that will prevent XSRF on forms generated by CakePHP.
Cake can be secured relatively easy (compared to self written php scripts):
http://www.dereuromark.de/2010/10/05/cakephp-security/