I have an html page that has a form and is communicating to a server via JSON requests, when loading (e.g. in order to remember user's previous answers) and when submit button is pressed (e.g. in order to save his new answers). Every user has a specific user_id that is located as an attribute in the url of the website. I have only HTML pages, CSS and Javascript that makes some simple functions, as well as received and sends the requests.
The problem is that the server needs an api-key for the request to happen, that I need to be kept hidden, but instead is easily discovered when the user sees the source code. I want this specific line to be hidden, but I guess this is not possible without any backend in the game.
I would like to know the easiest and fastest way to get from this state (just frontend, where every piece of information in the source code is totally insecure) to another where the api-key (at least) is not on the open.
I guess the solution is to use a server for that part but I need suggestion on the easiest transition from my code to another. I tried to use GWT, as I am a bit more familiar with JAVA backend application (but not with GWT), but seems like a big trouble, where I need to change my HTML, my Javascript and also the CSS that I have may not be useful, as well as I face a lot of problems when trying to read my parameters.
I know that it is not the best way but I do not have a lot of time to make it work, so sorry if it seems lazy (I am new to this type of programming), but I haven't found anything helpful and I cannot study for 2 weeks in order to be able to begin implementing it.
Is node.js (which is Javascript and I already have implemented the request sending/receiving in this language) easier than GWT for that matter? Will my sensitive data be secure in that way? I would be grateful if there was a similar sample, that I could start using for my implementation, as I haven't find anything that is specifically helpful for my situation.
Thanks in advance!
NodeJs is not javascript, NodeJs is specific javascript "interpreter" whose is purpose is mainly to be executed server-side. If you have an HTML page, it is likely to be loaded in a web browser (client-side), so not in a NodeJs environnement.
Everything that is hard-coded in the javascript of you web page is visible from the client, there is no way around that. So yes, you need some server-ish thing somewhere.
If you are not to manage a server by yourself or via PaaS, you can go for a serverless architecture. For instance, If you consider AWS which I know the most, you can easilly add some user management to your web page using Aws Cognito User Pool. Once a user is connected and have the good permission, he can be granted access to some other resources via a JWT token that you send along with your request.
Related
I creating a Web App that using Nuxt.js, with Server-Side Rendering.
I don't want expose my backend data, so I tried to use asyncData and Axios to request to my backend server.
But the Nuxt.js exposed my backend data to client with window.__NUXT__.data variable.
I tried remove this by using render:route hook, But It says
[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside p, or missing . Bailing hydration and performing full client-side render.
So I tried remove the script that making not matching error, But It makes stop working script at my site.
So the question: How to disable the client hydration(client-side virtual DOM tree rendering)? or How to stop exposing raw data?
I used asyncData with this code:
asyncData ({ params, error }: { params: { id: string }, error: Function }) {
return axios.post('(backend)', data).then(res => res.data ? ({ data: res.data }) : error({ statusCode: 400, message: 'Bad request' }));
}
You cannot stop the hydration of your SSR'ed content (not yet at least, it is planned to server only static content pretty soon tho).
Nuxt is aimed to add SSR to your day to day VueJS SPA. If you don't want the hydration, you're probably using the wrong framework here anyway.
Astro may be a better fit, to name just one. You could find more here too.
The DOM mismatch issue is explained here (reasons + solution).
How to hide things on the client side?
Short answer: you can't.
Long answer available here.
If you want to display something on a page, you'll need data.
Nowadays we're using SPAs to have a local state in the browser. Since it's local and under your eyes, the state is living in your browser, so you can't really hide it and also, why would you do that?
If you want to hide the data, maybe don't send it initially or send an image at least.
You could also make some obfuscation, but this will just be a band-aid and not really good on semantics/performance/etc...
If you have some sensitive data that you want to show only to admins or so, you could use some auth and rights checking. More details above, in the long answer.
If you really really want to hide data on plain sight, that is, you want to send data on client-side without exposing it, then you do not have a full solution for that as it is, but there are ways to achieve what you need, choose your preference based on your intent.
Not sending data to the client if you do not want to expose it
Yes, I know you have asked for the diametrically opposite, but, before you read the really, really unconventional and often difficult approaches, first, let's ponder on whether you really need this indeed. The alternative would be to just not send this data to the client at all, but rather work with this sensitive data on the server. It is the scenario you will need 99.9999% of the cases of web-development. (the number is my subjective estimation, not the result of a representative statistical research)
Email, chat, SMS, paper mail, smoke signals, morse messages
You may need to send that information for the client, but this does not automatically mean that you will need to send it to the client-side of your website. You could send the information using some other channel, just make sure that it's trusted and reliable. For this reason I don't really recommend the use of smoke signals.
iframe
Now to the technicalities. Modern browsers protect against the scenario when you have webpage1 opening webpage2 in an iframe if they happen to have a different domain. So, you can create a domain that's different from the one your main page uses and show whatever you want to the client by calling a page of your brand new second domain (via HTTPS, of course), using minimized Javascript and closures. If you need communication between your iframe and your main page, then you can use messaging between the two, see Communication between tabs or windows.
A possible objection may be that one can still see the network tab of his/her browser where the actual received data is being shown as well as the possibility to debug Javascript. Well, bad luck. We cannot send the data to the client without sending it to the client. If this caveat is too much of a risk, then read on.
Encode the content you want to avoid from exposure
Yup, it will create a lot of difficulties and sometimes you will wish you never did it, but you can encode your top secret data and even if the user has access to it, he/she will have no idea what it is. But in this case you will need to face the problem of encrypting/decrypting your data whenever you use it.
You can use visual representation of your data
Like an image, an svg or some other kind of generated captcha-like content, but don't send it a file, because a third-party watcher may just download it. If you generate that inside an iframe, then your data is difficult to mine. Oh, wait, but what if the hacker looks at your screen from behind your chair?
Write your own browser (extension?)
You can implement a browser or a combination of browser extensions that will handle this and use HTTPS. But what if the spy has a lucky day and deciphers it? What if you have a virus?
Bottom-line
By the sheer fact that you are sending data to the client-side you will have to accept some risks. There is no way around it. You can reduce those risks, but it's always safer not sending the data than sending it.
I am making a small payment system, basically it's just a point system, you pay say 1 USD and you get 100 points which is used later on in a game project to get bonuses. It's a script for game servers, something like a user panel.
Now, the script system is ready, but I'm afraid to give it away, since than someone will share it and it will spread all over the gaming area. What would be the solution keeping it working only if I give them a permission?
I thought about re-making whole code and make it work on my website but I don't think that people will want to put their SQL data to website that located NOT on their host. Please help me out, at least with some clues, maybe its possible to make some widgets? or maybe some license system?
I'm really lost.
You should implement the logic on the server side as an api REST call and include in the script only an ajax call to the api. You can limit the use of the api through an api key that you'll provide only to qualified sites.
You'd need to implement some sort or serverside authentication/api so that only varified users can use the script. Much like how software checks a licence.
On script load your javascript could make a ajax call to a server passing through the users IP, auth key, username etc etc.
This can then be varified on the server, maybe returning a dynamically generated url containing a javascript file which contains your business logic
(so that urls are dynamically generated for that users session only)
That way people cant hot link the script, and the script you give out is solely the ajax call
(With the business logic script injected on auth)
I am at the stage where I am thinking of integrating a social login method into my site. Of course my first one will be the facebook login before moving onwards.
Basically my question is : Which language is best for this type of OAuth connection, and which is going to let me do everything I want?
This will encompass all OAuth connections in general eventually, but specifically Facebook for now.
From what I have read of the documentation, the JavaScript SDK allows you to login, and connect to the open graph API - which in turn will allow me to post / upload etc etc. This is also available in PHP.
From experience which is the more durable route to go?
PHP or JAVASCRIPT
The best and recommend way to authorize users is the JavaScript SDK (FB.login). No redirect needed (better usability), very easy to handle, no PHP needed (the new PHP SDK needs PHP 5.4+). Use PHP only for stuff that involves usage of the App Secret or Extended Access Tokens. And for cron jobs, obviously. You can even just forget about the PHP SDK and use your own CURL calls.
Btw, security is no problem, you should just activate "appsecret_proof" in the App Settings.
More information about appsecret_proof:
https://developers.facebook.com/docs/graph-api/securing-requests
http://www.devils-heaven.com/facebook-php-sdk-4-0-tutorial/
One more reason (and one of the most important ones) is the possibility to refresh Access Tokens (=User Sessions) easily without page refresh by using FB.getLoginStatus.
And another reason is that you need to upgrade to new PHP SDK versions on your own. The JavaScript SDK does not need any upgrades, in the lase few years you only had to change one or two parameters in some cases, the SDK gets downloaded from the Facebook servers.
Also, if you add Social Plugins, you need the JavaScript SDK anyway.
TL;DR PHP/both
I'd really recommend PHP. You'll want to store the login in database. If you do it via JS, you'll need to make an Ajax call to the server, which is not really that secure.
Having said that, they are targeted for different uses. JS is for frontend more, while PHP is for backend (db storage, checks, actual site login, etc). Using JS will let you generate the buttons on the fly, while using PHP you'll need to do some more coding.
Somehting else, the php library will get updated from time to time and you'll need to keep up after testing. JS also, but it's easier, since the code usually works.
If you only want one, use PHP. You can control what the code does and JS will not break your site since it's written by you. However, I'd recommend using both since you will probably want more than just simple login
Edit:
As facebook states, use PHP SDK: Usually this means you're developing with PHP for a Facebook Canvas app, building your own website, or adding server-side functionality to an app that already uses the Facebook SDK for JavaScript.
https://developers.facebook.com/docs/reference/php/4.0.0
The best route would be to use both, together. Some users might have javascript disabled or you might do something within your javascript code that will not work on some browsers. So as a fallback method you can use php api.
Going with only php would be solid and will work regardless of what the users client is, but you can make the user experience better with javascript.
Still, in most cases you'll end up having to use both.
I have just spent the afternoon playing with the JavaScript SDK for facebook and I have to admit I think this is going to be the best option for what I need.
If anyone else is reading this, it may not be perfect for you - but with the way my application has been built I think it is a perfect fit. Here is why :
My standard login system uses JavaScript to grab my form data, then validate, which then passes the validated data via AJAX to a PHP validation script. Which in turn returns a JSON response to the original AJAX call. If my call comes back with "ok" : true then we are good to go basically.
The way the facebook JavaScript SDK works is almost a perfect little jigsaw puzzle to bolt onto the system I am using. All I require is a little bit of profile data, to then keep a record of this user on my system. THIS is provided by facebook, then validated by myself.
However, other social network logins may not be as nice and simple to use as the facebook API, so I could end up changing my mind on the overall system. For now just using facebook, I think the JavaScript SDK is absolutely spot on, as it just gets the information for you to run through your own validation on site. As I said this is a perfect fit for my system however it may not be for yours.
I'd like to present an idea to you that I think might help the privacy of the average user. I would appreciate any comment or suggestion on this.
I've been struggling for quite some time now with the need for a simple tool that I could share and use with my contacts who are only average users and not familiar at all with any cryptographic technology or the current tools available.
I'm planning to create a solution where one can easily encrypt a text message or a file with a single password and send it in email or chat or through whatever channel to somebody else. The solution should be entirely platform independent and usable without the need to install any extra softwares.
There are some text encryption websites out there that run client side encryption from JavaScript entirely. I find this approach currently the only possible solution. Also, there are libs for JS that already implement encryption:
http://crypto.stanford.edu/sjcl/
http://code.google.com/p/crypto-js/
Though the mentioned approaches store the message on their server, requiring you and your contact to trust it entirely. Because the server might present a different JS code to the user when visiting it after he gets the message by steeling the password and so revealing the secret.
While many think that it's not a good idea to do anything regarding cryptographic tasks in JS, I believe there is a need for a tool that is really platform independent (can be used on any tablet or PC) and still incredibly easy to use. The idea behind this is that I believe something is better than nothing. Sending information in plain text in email for decades with our current technology is wrong in most cases. There are times when we do need to share sensitive info via email and the other side might have any kind of system.
I intend to avoid the use of public key cryptography for the following reasons:
- it is very complicated to setup including the signing of each others' keys
- complicated to use it
- the user can loose his keys
- most of the time it needs and external software to be used and installed too
- a single password can be easily shared personally one time with my contact and he or she can keep it written on a paper wherever
The solution I came up with could be the following:
First of all, the browser and the operating system under it should be considered trusted.
There would be a static index.html page with embedded JavaScript. The page shows a textarea for the message and a textbox for the password. When hitting enter, the JS code generates a URL that itself will contain the encrypted message in base64 encoding. After digging I figured that 2000 bytes can be used for URLs just fine in every cases, so 1600 or 800 characters could be enough for short messages. This still needs planning.
So the encrypted message would travel with the URL. The website serving the index.html would of course use SSL with a valid certificate. While it seems an easy taks, of course it is not. The JS implementation should be carefully created to avoid easy attacks on it.
(URL shortener services could be used for it too).
Also, the question stands: How can I make sure that my contact can be certain about the origin of my message?
Well, the other side has to check if the domain is correct. Beside this, the implementation must avoid the rest of the attacks. If the URL gets changed during the travel of the email, then maximum the other side won't be able to decode the message with the password. That's what I believe. That it can be implemented this way.
About the file sharing. The solution should have a possibility to browse for a file, then encrypt it, then put it out for download to the user. This is just for him to be able to create the encrypted form of the file without the need for external tools. Then he could upload it to the cloud of his choice wherever (Google drive, Skydrive etc) and use that link in the URL of the JS solution to send it to his contact.
So if another link travels with the link, then the file from the remote host gets downloaded, decrypted and sent for download. All in his browser. If it's an encrypted message in base64 form, then it gets printed on the page after decryption (by the user providing his password of course).
Pros compared to other solutions:
- no need to implement a storage because no message nor file will be stored on the server, so the big players' services could be used
- therefore no need to reimplement the wheel regarding the storage question
- no need to trust a 3rd party because the server could easily be ours because it would be extremely easy to set up and serve it
- easy with even a free provider to host the static index.html
- because of its simplicity, the server can be hardened much better
- easy to encrypt with it in practice
- if one needs it, he could use the index.html by clicking on it from his desktop too, but that's not part of the original idea
My questions to you all are:
Do you find any flaw in my theory above? Could this really serve the average people by providing a usable tool for them that is more than nothing in times when they do need to send sensitive info to others?
Or does anything like that exist yet? Are there any better approaches? Different technology maybe?
Thank You.
I am attempting to develop a pure javascript web application using Dojo. The problem I face is one of restricting access to portions of the application. Authenticated users should be able to access everything, whereas non authenticated users should only be able to access a login screen.
The issue is that nothing (that I am aware of) will stop a user from opening up a browser javascript terminal and entering something like: app.displayRestrictedContent(); and thus gaining access to a screen intended for authenticated users.
I have implemented an ajax based login; all ajax calls are secured with a session. So while the non-authenticated user can load a restricted screen, they wont be able to fetch data for it. But still, It seems wrong for this screen to be arbitrarily accessible.
Am I trying to do the impossible? It seems silly to write code such as if (user.auth) app.displayRestrictedContent(); when it's so easily circumvented. And this leads me to believe I am missing something rather obvious to everybody else. I can't find much information at all on pure javascript based apps and authentication models.
But still, It seems wrong for this screen to be arbitrarily accessible.
Because it's client-side code. Anything you write in js, or get compiled to js, expect it to be readable by the users.
Am I trying to do the impossible?
you can dynamically load js modules after the user authenticates. So at first, just load 1 login module. When the user logins, if successful, the server return a list of js modules to load, if not, return empty list. It also helps improve load time when the users come to your website.
I'm by no means an expert, but here are some thoughts I've made on this. I don't think you've missed anything (if so, I have too) - I think this is a pretty fundamental issue with all client applications, whether it's a compiled executable or a Javascript.
Of course, the compiled executable is not particularly hampered by it, because it's been made into machine code which is very difficult to read or decompile into anything useful. With Javascript however, the application is often served exactly as you wrote it, and so it's easy to modify and reason about.
That brings me to the first semi-solution: obfuscating your Javascript. If you use Dojo's build tool with the shrinksafe parameter, all unnecessary whitespace is removed and all identifiers are shortened, making the code quite difficult to read. I called this a semi-solution, some may say even that is giving it too much credit - I myself still think it's worth doing. After all, the shrunk code downloads faster too!
The second measure I take in my apps is to separate the different parts into "build layers". For example, in my build profile, I'll have something like
dependencies = {
..
layers: [
{ name: "../myApp/Core.js", resourceName: "myApp.Core",
dependencies: ["myApp.Core", "myApp.Foobar"]
},
{ name: "../myApp/modules/Login.js", resourceName: "myApp.modules.Login",
dependencies: ["myApp.modules.Login", "myApp.modules.LoginUi"...],
layerDependencies: ["../myApp/Core.js"]
},
{ name: "../myApp/modules/Secret.js", resourceName: "myApp.modules.Secret",
dependencies: ["myApp.modules.Secret", "myApp.modules.SecretUi"],
layerDependencies: ["../myApp/Core.js"],
authentication: 42
}
]
}
Now, instead of serving the built JS files directly as static files, I let the requests go through a controller in my server-side application, which checks if the JS layer requires authentication and whether or not the user is logged in with the necessary access.
This does have certain cons. The JS files aren't cached, and if I had all my JS in one build layer, the application would probably load slightly faster. There's of course also a limit to how nuanced it's worthwhile to make the layers. More layers mean more hassle, but also more finely grained module access.
I'd be interested to hear others chime in on this as well. It's a good question.
When a user successfully logins the server should provide him with a session token. The Afterwards, whenever the user requests a resource (either via just redirecting the browser or via AJAX) he shows the server his session token (either by storing it in a cookie and sending it automatically on all requests or by explicitely passing it in the body of an AJAX request)
The server can then use session tokens from the users to control authorizations server-side, rejecting any request with an invalid or outdated token.
https://en.wikipedia.org/wiki/HTTP_cookie#Session_management