My plugin is has flows depicted by the diagram below:
The requirement is to make the onclick transaction happen after authentication. That is, only if the owner of the domain which contains page.html has registered with my site (for instance www.MyPluginJS.com/register) can he/she use MyPlugin.js.
My registration portal spits out a Client ID after successful reqistration.
My question is:
What is the best approach I need to use in order to make the onclick transaction secure?
What are the other parameters (eg: MD5 fingerprint) I may require to make sure that the transaction happens securely?
Are there any existing frameworks (for instance OAuth) that I can leverage on?
I need a way to stop people from using MyPlugin.js who haven't registered.
I am inexperienced with security techniques but I can manage to code.
Thanks in advance :)
You could serve the JS file using some server side language and add a key/value pair to the request for the js file, pe: MyPlugin.js?key=someValue. Your script could compare the value to some DB table values where you store authorized users.
HTH,
Miguel
By using jQuery, you can take advantage of the function $.getScript(url) to load a javascript file from server-side avoiding the use of <script> tag.
The idea is to point the getScript function to a server-side script that will first validate your user's session and in case the session is valid, it will return your javascript file content to be loaded or a void javascript file otherwise.
I think you should use a session created on the server side to ensure the user is logged in. You can then check client side (for user convenience) if the session variable is set, and then validate the session server side (for security) to avoid user tampering with client side code.
You could then use AJAX to load the contents of the plugin page into an iframe. jQuery makes AJAX much easier to manage.
So the simple answer from me is to use server side scripting, and session variables to ensure security, and jQuery and AJAX on the client side for user convenience.
Related
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.
I'm in the process of migrating one of the applications from old system in separate/new system. My Single Page App is built in JQuery/HTML5/CSS/AJAX on the front end and ColdFusion on the back end. Before I start developing my new framework and login page I was hoping for some helpful hints on security and best practice for this purpose. I saw blog post by Raymond Camden where he explained how Login page can be done in JQuery/AJAX and ColdFusion.
Link: https://www.raymondcamden.com/2009/03/24/Simple-example-of-a-Form-post-to-ColdFusion-with-jQuery-Login/][1]
He explained the process but I'm wondering about next few things. My main Login page should I use .html file or .cfm file for login page? Also is there any security risk by doing login process through Ajax from submission? I don't have experience in creating Login system and any help would be appreciated. If anyone can provide some useful blogs or code examples that will help in this process please let me know.
I would love to write this as a comment but the question requires a long answer and can be approached many different ways. Please take this with a grain of salt.
Generally, what I have found is the best practices when dealing with any user input especially when the input is being captured in a specific database is the following things:
Client Side Validation (can be done with JavaScript or HTML5 required attribute, if done correctly can increase security on login form and prevent cross site scripting attacks)
Server Side Validation (can be done with ColdFusion)
Using prepared statements (this is extremely important) against whatever database you decide to use. This can be done with ColdFusions <cfquery></cfquery> tag and make sure to add param for one of the attributes. Documentation is here:
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-p-q/cfqueryparam.html
As for the file, it's subjective because you can have your client side validation on let's say your login page and if they pass client validation, it'll get redirected to a .cfm file that'll perform a server validation. Or you can just have both client side and serverside validation on a single file in which case the file would need to be .cfm
As for your question about the ajax form submission. Yes their are security risks which plays a big role in how you would write your server side validation
When you're performing checks against your database. The most important thing is making sure you sanitize your query inputs whether it be authenticating a user, adding, updating or deleting from the database.
Why not use the API manager to do this for you? (it comes free with CF2016 enterprise)
Otherwise lookup the OWASP functions and form security sections of the docs.
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 wanted to load HTML contents dynamically, such as updating a Bootstrap's modal dialog contents via AJAX call (because refreshing the page and showing the modal again is weird), but before I do that, I want to know what risks that I will need to concern when doing so, and possible solutions.
The main reason to do this is that I'm developing a portlet for Liferay, and I wished to update the content of my portlet dynamically without refreshing the whole page.
Of course I could return data in JSON from my server to client, but I will have to write complex client side logic to update the DOM, which the logic is probably done easier in, say, JSP
Assume the webapp is HTTPS only, not sure if this will help with anything.
Based on the assumption that the webapp is HTTPS only, it would be very good to let all AJAX calls also use that. This will not create a breach of mixing unsecure and secure connections, and the warning dialogs, which browsers give.
The only risk can be caused by cross-site scripting, if parts of the HTML is generated elsewhere or if parts of it is based on unvalidated user input.
Solutions for that is to always validate ans sanitize the input from other sources. More information about this can be found here: https://www.owasp.org/index.php/Data_Validation
Perhaps you chosen the wrong framework for the job and would have consider something like an client side rendering where you would bind json data to the view (eg: angular, ember, backbone or knockout)
Consider using Element.innerText or $(Elm).text() instead of Element.innerHTML or $(elm).html() when possible
Perhaps it will be a good idea to encode everything that a user can change before you save it to the database or when you are rendering the view
However if you do allow some html you would need a sanitize plugin with a witelist approtch to strict the allowed tag & attributes
the only diffrence with http and https is that it will be much harder for a man-in-the-middle attack to read/intercept/change the content of the request & the response