I have a php script in my application, this script should be triggered only by a js script from my application.
Actually, I'm trying to convert js errors to php errors, so I intercept js errors and send them to a php script.
The problem with this approach is that then anyone is able to use the php script as well (and possibly spam the service).
I'm looking for a general approach here or for ideas to make a secure service.
So far, I found those options:
create a unique php key that one (the js script) must send in order to "post" an error to the php script.
That's my best option for now, but unfortunately, so far, no matter how complex my key, or logical secure system is,
I cannot find a 100% "uncrackable" solution (I can make it pretty hard for a potential spammer though).
use the html5 FileSystem api, but the problem is that the files that we can write to are browser dependent.
And then maybe watch for changes in those files, and notify php when a change is made.
Do you have other ideas in mind ?
Related
I am building my first application on React.JS and I am wondering how to implement simple security in on the client-side because there are some vulnerabilities that I see such as if you view page source the script tags show you all the Components that you made with all the functioning and rendered pages, Also if there is a basic method to stop XSS from happening that I can build on I would like to see that as well.
I am concerned about how anyone can view a page source on react and see the components from the script tag
You're not going to be able to prevent people from looking at the code source on the browser, since the browser has to see it and render it. You can make it a little harder for people to get to the inspect element, but there is always a way to get to it.
As for XSS, all you can do on the client side is validating input and sanitizing, but you can get around that via watching the network traffic and submitting bad data directly through your own http requests.
Client side is just that, served to the client.
What do you mean by sources? It's still a JavaScript and everybody can see the sources, but they will be uglified and minified by Webpack.
Regarding XSS. Don't worry about it using React. Your code is already protected thanks to JSX. String variables in views are escaped automatically.
I suggest you to secure you're service in back-end, because anyone can request to the server trough Postman and can record and repeat your request in BurpSuite;
then use security solutions in your back-end code after that use Object Schema validator in your React app to prevent users XSS attacks.
I'm using a javascript scripting engine for a MUD i'm playing, they have a javascript client hosted on their server. I'm wanting to store some information in a database and access it from the client (or inject it somehow into the client) but I'm not seeing how I could do that.
Basically I can write javascript files into the trigger section of the website and they fire. It has Javascript and JQuery options. It does not have a database option on their end, which is why I'm trying to add it myself.
I know client side javascript has a lot of restrictions on it, so I'm not sure how far I could really go with this.
I think you might be able to do this, but it's going to be hacky.
If you're able to attach a script node to the dom, you can trigger GET requests with no origin restrictions wherever you want. You would do that to your own backend.
You would have to throw away all good practices and use GET requests with a lot of query params so send data to that (your) backend.
You would have to write the backend so that it does whatever you want with the data, e.g. store it in the db.
You would have to make sure you return valid js to the client, even if it's only to dismiss it.
Alternatively...
you could load an iframe to a site you control, and change the iframe src with the data, and then do with the data whatever you want (like sending it to some bakcend of yours properly) in your site (that's loaded in the iframe) by detecting changes in the url...
i'm new to use javascript
now i can edit my javascript code from browser using firebug.
any idea, to detect or avoid edited javascript from client browser ??
You can't.
You can (and should) use server side code to check that any data sent to the server is sane, but you can't do anything to stop people sending whatever data they like.
It is not possible to prevent people from tinkering with your js in the browser, since js is sent as-is, from the server.
You can however obfuscate your js to make it slightly harder to edit. (Another link)
I am writing a JavaScript application where I plan on host the code on a CDN. Now I plan to include this code to my clients' sites. However, I have a problem, I want to use AJAX to communicate between the client and the server. Now, from my understanding of XSS, this is not possible.
Ex:
User visits site.com, where a script tag's source is pointing to a file on cdn.somedomain.com
The script on cdn.somedomain.com fires an event.
This event will communicate with a PHP. I know it is possible for the script from cdn.somedomain.com to request documents on site.com. However, is it possible to send data back to a PHP file on cdn.somedomain.com?
Thanks for helping an entrepenuer! :D
The short is I think this is possible, but it depends on a couple of things. The same origin policy is a weird thing in that it won't allow cross domain reads, but will allow cross domain writes.
I think a way you could accomplish your goal is by making a GET request (minimally by creating an iframe, img, or whatever else that pulls a src) or possibly even using AJAX. If your goal is to only send data, then that should be fine. However, if you want to read this data back then I think that'll be a little less straight forward. I can't really answer that right now - especially without knowing more details about your system setup.
Sounds like a weird use of a cdn. Normally cdns serve static assets, so you wouldnt put a php file there. In fact the cdn wouldnt normally run dynamic server side code at all.
You can address the problem in several ways. Newer browsers support CORS and cross domain ajax. The cdn would then have to use the Access-control-* headers. You could also look at something like easyXDM, which works in older browsers.
I have a series of JSON Objects I want to save locally on my server. I am attempting to avoid any server-side script like PHP as required per demand of whats being built. I know its a security risk, but that in this case is not a particular worry. So that said is it possible to actually write to a file and or get its contents via javascript with or without the help of a lib such as jquery?
I should mention I am attempting to avoid ActiveX as I know this is an IE only feature and the software we are developing is planned to be Cross Browser supported
So that said is it possible to actually write to a file and or get its contents via javascript with or without the help of a lib such as jquery?
Nope. You will need something running on server side that can receive your JavaScript input and write it to the server.
Internet Explorer's proprietary file writing functionality is for writing local (client-side) files only.
You can read a file using ajax, but without a server side language you cannot write a file to the server.
https://developer.mozilla.org/en/ajax
No. Javascript runs on the client. You need server-side code to access the server's file system.
Client-side JavaScript can only send data to a server, there's no way for it to tell the server what to do with the data.
To save data to a file or db on a server, you'll require a server-side script of some sort (could be server-side JS with Node.js). If all you need is persistent data, you could store some JSON strings in localStorage or in cookies as needed. They wouldn't be shareable that way though.
Yes, you can use AJAX requests in JavaScript without using jQuery. However, jQuery will save you an ungodly amount of time and cross-browser testing.
But, as others have already said, you can't write server files without server code.