Can you share your views on Creating a private and protected members in Javascript.
I mean really protective not just convention like Douglas Crockford said.
Do not use _ (underbar) as the first character of a name. It is sometimes used to indicate privacy, but it does not actually provide privacy. If privacy is important, use the forms that provide private members. Avoid conventions that demonstrate a lack of competence.
"use strict";
function MyMain(){
this.checkauth=false;
}
MyMain.prototype.init=function(){
return Object.create(this);
}
MyMain.prototype.authenticate=function(key){
//resp is server response hold true for the given key. here validate method will interact with server and get concerned response
var resp=validate(key);
if(resp){
this.checkauth=true;
return true;
}
return false;
}
MyMain.prototype.test=function(){
if(this.checkauth==true){
console.log("this is working")
}else{
console.log("Not authorized")
}
}
Well i failed in explaining see the Edit i have made.
i have no intention of making authorization on client side. I made it on server and making private member true saying server has validated the user and my question is how to make this secure.
and users who have access to my Javascript file can read all of it and authenticate like this.
var main=new MyMain();
main.checkauth=true;
main.test();
Looking for help on creating secure authentication via javascript.
While there are various ways to mask variables and make then tricky to access, the main benefits of these techniques is that they stop you from accessing them by accident.
The owner of the browser has access to all of the code and all of the data that you send to the browser.
You can't stop them accessing it.
If you want to do secure authentication then you must do it on the server.
i have no intention of making authorization on client side.
If you weren't doing authz client side, then users setting main.checkauth=true; wouldn't be a problem for you.
You need to not send the data and JavaScript that should be available only to authorized users if the user isn't authorized. At the moment you seem to be authorizing on the server but sending all the data/JS that is for authorized users to the client regardless (just with a little bit of client side code that says "Please don't look at this").
Related
I have a job script that is executed every 5 minutes by the scheduler. This script search for specific Workitems and change them. The script is working well if I execute it manually because then I am the "current User" and have enough permissions to write in the svn. BUT if the scheduler execute it the current user is: "polarion" and he did not have write acces to the svn which is a bit strange but ok.
The error is:
Caused by: com.polarion.platform.service.repository.driver.DriverException: Sorry, you do not have access to the Subversion Repository. Please contact your Polarion or Subversion administrator if you need access.
at com.polarion.platform.repository.driver.svn.internal.JavaSvnDriver.handleSVNException(JavaSvnDriver.java:1732)
at com.polarion.platform.repository.driver.svn.internal.JavaSvnDriver.endActivityImpl(JavaSvnDriver.java:1564)
at com.polarion.platform.repository.driver.svn.internal.JavaSvnDriver.endActivity(JavaSvnDriver.java:1496)
at com.polarion.platform.internal.service.repository.Connection.commit(Connection.java:736)
... 42 more
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: CHECKOUT of '/repo/!svn/ver/54/Sandbox/7023/.polarion/tracker/workitems/100-199/7023-193/workitem.xml': 403 Forbidden (http://localhost)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:68)
I can´t find the user "polarion" in the user Management so I could not give him more rights.
Is it possible to execute the write access from a other user or something similar?
the user "polarion" is used internally for reading information from Polarion's SVN Repository. It usually not writing ("committing") into the repository as this is usually done under the useraccount of the logged-in user.
There are two solutions to your problem:
The quick and easy fix: modify the svn access file, so that polarion user has write access to the repository. This is quite easy doable from Polarion itself with the build-in access editor under administration->user management->access management. This is potentially unsafe as the password of the polarion user is in cleartext in a config file on the server so anybody with access to the server can modify the SVN-Repository.
use the ISecurityService.doAsUser(..) function to perform your action as a different user. Usually you can put the credentials into the Polarion Vault to retrieve them without exposing usernames and passwords.
Here is an example:
subject = securityService.loginUserFromVault(vaultKey, vaultKey);
retVal = securityService.doAsUser(subject, new PrivilegedAction<Object>() {
public Object run() {
Object ret = null;
try {
ret = doAction();
return ret;
}
}
});
Needless to say the second method is the safer way to work, but it is more work as well :)
I have a node.js REST API and I want to restrict POST/PUT/DELETE calls to a predefined list of "sources" (web applications which I do not own the code).
The only way I see to achieve this is to put a token on the client-side (something like Google Analytics in JS files) but I have no idea how to secure this since the token will be accessible in the static files.
What strategy should I use ? JWT and OAuth2 seem not indicated since it requires first user authentication, but what I want to authenticate is not user but webapps.
Your question is slightly unclear. You could mean either (a) that you want to strongly encourage the user to use the app and prevent other code from maliciously making your user perform an action, or (b) that you want to absolutely prevent your user from using other code to access your server.
The first option is possible, and indeed a very good idea. The second is impossible, based on the way the Internet works.
First, the impossibility. Essentially, client-side code is there to make life easier for your client. The real work will always be done on the server side -- even if this only means validating data and storing it in the database. Your client will always be able to see all the HTTP requests that they send: that's the way HTTP works. You can't hide the information from them. Even if you generate tokens dynamically (see below), you can't prevent them from using them elsewhere. They can always build a custom HTTP request, which means ultimately that they can, if they really, really want, abandon your app altogether. Think of your client-side code as merely making it easier for them to perform HTTP requests and abandon any idea of preventing them "doing it wrong"!
The much better option is CSRF protection, which gives the best possible protection to both your server and the client. This means sending a generated token to your client when they first log on and verifying it (either by looking it up or decrypting it) when they send it on every request. This is the basis of JWT, which is a beautiful implementation of a fairly old system of verification.
In the end your API is public, since any random website visitor will have to be able to interact with the API. Even if you use tokens to restrict access somewhat, those tokens by definition will have to be public as well. Even regularly expiring and renewing the tokens (e.g. through a backend API, or by including a nonce algorithm) won't help, since those new tokens will again be publicly visible on the 3rd party's website where anyone can fetch one.
CSRF protection can help a little to avoid cross-site abuse within browsers, but is ultimately pointless for the purpose of preventing someone to write an API scraper or such.
The best you can do is use the tokens to identify individual site owners you granted access to, vigilantly monitor your API use, invalidate tokens when you think you're seeing them abused and contact the site owners about securing their tokens better somehow (which they'll have the same problem doing, but at least you have someone to blame cough cough).
You can use hmac to secure this :
Each client has a unique couple of key public/private (for example "public" and "private").
When client send request, he has to send a nonce + his user public key + the hmac of nonce+public key with his private key.
When server handle request, the server retrieve the client according to his public key, get the secret key of the user, then verify the signature.
Client, sample call on /api
var nonce = "randomstring";
var pk = "aaa";
var sk = "bbb";
var string = "pk="+pk+"&nonce="+nonce;
var crypto = require('crypto');
var hmac = crypto.createHmac('sha512', sk).update(string).digest('hex');
// send this payload in your request in get, put, post, ....
var payload = string+"&hmac="+hmac;
request.post({uri:"website.com/api?"+payload}, ....
And
Server side, security check
var nonce = req.query.nonce;
var pk = req.query.pk;
var hmac = req.query.hmac;
// retrieve user and his sk according to pk
var sk = getUser(pk).sk
// rebuild payload string
var string = "pk="+pk+"&nonce="+nonce;
var crypto = require('crypto');
var hmac_check = crypto.createHmac('sha512', sk).update(string).digest('hex');
if(hmac_check === hmac) { // request valid }else{ // invalid request }
My app consists of several PHP endpoints which are accessible via AJAX. The problem is they are also accessible via anyone who makes an HTTP request to the same endpoint. I can add checks for HTTP_X_REQUESTED_WITH and HTTP_REFERER as specified in this answer, but these can be spoofed. I could add a secret key that needs to be posted with the request, but anyone viewing the javascript and/or the console would be able to see this key. What is the solution here?
People often think that because they're using Ajax requests regular sessions don't work. They do.
If you have an endpoint to delete something from the database that's visible in the source code, such as:
example.com/user/1/delete
You can protect this request from non authenticated users the same way you would when using a non Ajax HTTP request in the browser. Using sessions. If the user has the privileges to remove users, this route will work, otherwise return an error (or do nothing).
You can also protect an API using OAuth. There's a great document here that explains how it works: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
Most of the answers are not helpful if you have your app and your api on separate domains for example app.example.com and api.example.com - in that case sessions won't work and you would have to turn to OAuth which is quite a big hammer for such a simple problem.
Here is what I would do:
I assume you have users in a database and a unique identifier like user_id=12345. I also assume that you have your Jobs in a Database and they also have unique ID's like job_id=6789.
First on app.example.com you encrypt both IDs with something fast and easy like Blowfish:
$secret_uid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($user_id));
$secret_jid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($job_id));
I assume your endpoint would work somewhat like this:
api.example.com/jobs/delete/<job_id>/<user_id>
so now from Ajax you call that endpoint, but instead of calling with plain IDs
api.example.com/jobs/delete/6789/12345
you call it with the encrypted IDs:
api.example.com/jobs/delete/6A73D5B557C622B3/57F064C07F83644F
On the API side of your software you decrypt the parameters:
$jid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_1>);
$uid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_2>);
Now you can search your db for uid and jid and perform whichever task you were planning to do. Make sure that a user can only delete his own jobs of course.
I admit this is not a 100% solution, but it leaves an attacker with a lot of guess work - he would have to guess the user_id and a matching job_id, the encryption algo and your secret. It does not protect against running millions of brute force attempts to guess a matching pair, but it put's the odds in your favor (and you should have some sort of quota limitation protection of your endpoints anyway).
Good luck!
There isn't one. If you give someone some data, then they can process it in whatever way they like. You can't control what happens to it after it leaves your server.
Likewise, you can't control what data they send to the endpoint.
it is very important for a developer to put authentication for API or web services. dchacke and BugHunterUK has given perfect answers, I just want show you simple code I use to make very simple and easy to use authentication.
Adding Session for the authentication
you can add session, and session timeout for your APIs so, only your app can use this, you can start session when front page of your app is loaded, you can set timeouts and also restrict the different service for different users by sessions.
General Idea how to do that
<?php
if(!empty($_SESSION['api_session']) && $_SESSION['api_session'] == 'usertype'){
//usertype comprise of what access you want to give
//guest, registered user, stack holder, admin etc.
...
header('Content-Type:application/json;');
echo json_encode($output);
}
I have a very simple node.js app built on express which has been handling authentication using a session memory store. Basically a user logs in by:
app.post('/sessions', function(req, res) {
// check username/password and if valid set authenticated to true
if (authenticated){
req.session.user = req.body.username;
} ...
});
Then in each call from the browser a requiresLogin middleware function is called which checks to see if that user property on the session has been set.
I'm now transitioning the app to basically just provide a service that may or may not be consumed in the browser, so instead of using cookies/sessions, I'm considering changing the system so that one would post to /getToken (instead of /sessions) which would return a temporary random token associated with a user's account that could then be used for a period of time to access the service. Using the service would then require a valid token to be included in each call. (I assume this would be better than passing the username/password each time so that the password would not have to be stored in memory on the client's computer after the call to get token?)
Would such a system basically be just as secure as the above current system or Is there a much more standard/safe way to handle this? What's the standard way to handle something like this?
Thanks in advance for you help!
What you are looking for is called an HMAC and there is a great article here to get ideas on how to implement for your service.
As to whether session based security is more secure than public/private keypairs is widely debated and really depends on the implementation/application. In your case, since you want per request authentication on a public facing API, the HMAC is the way to go.
I've been reading about CSRF and XSS vulnerabilities for a few days now, and trying to come up with a solution that's 1) easy to implement and use, 2) uses Javascript to do a lot of heavy lifting, and 3) makes it virtually impossible to perform a CSRF attack against.
I haven't seen a solution like the one I'm about to describe. I'm hoping this doesn't mean that it's leaky.
I've come up with the following solution, based on my knowledge of AJAX and JS. This code assumes the user has passed through a login screen, and a session variable has been set on the server and in a cookie, with the same values.
It's easier to paste the code in and document it, rather than explain what it's doing. This code would be run in the page the user sees immediately after logging in:
<script>
// this is the constructor:
function Controller(){
//the following 2 variables are private, and inaccessible via JS calls
var secretToken; //this holds the session token, but cannot be read by the browser
//returns the session token from the server
var x = new ajaxObject('AJAX/retrieve_session_cookie.lasso');
x.callback = function(responseText, responseStatus){
secretToken = responseText;
}
//this is a private function, again inaccessible via JS calls
function getCookie(){
x.update();
}
//the following 2 functions are publicly accessible
//just a test function to ensure that secretToken is invisible
this.tell = function(){
alert(secretToken);
}
//privileged function that calls a private function, to load the token into a private variable
this.initialize = function(){
getCookie();
}
}
E = new Controller();
E.initialize();
</script>
The variable secretToken can't be read by the user, as it's a private member variable of the controller object.
In retrieve_session_cookie.lasso, I'm checking for a valid session, and matching the session variable with the browser's cookie. If both these conditions are met, the session variable is returned in plain text, where it's set as secretToken in the object E. By double-checking to see if the cookie matches the session token, I would hope that it would be impossible obtain the session token via CSRF, as it can't forge a cookie. Typing in 'AJAX/retrieve_session_cookie.lasso' would return nothing, unless it was typed in by the user while in a valid session, and from the user's computer only.
Also, now that my controller has local access to the session token, I could 'burn in' the session token with every AJAX request, so I don't even have to think about it passing a token anymore, each time an AJAX file is requested. All the AJAX objects and requests would be initialized as private members in the controller object's constructor, so nobody could access / modify the callback functions to disclose the session token.
Passing the session token with every AJAX call would protect every other AJAX file, as they would all perform the same check for the cookie matching the session token before returning any data. And, in my programming, there would be one less variable to worry about.
If I were to move ahead with a controller implemented this way, would there be ANY way for the token to be accessed / exploited, either by the user or a malicious coder via CSRF?
First of all it is trivial for a user to obtain your token and for CSRF this doesn't matter at all. Anything you transfer to the user can be intercepted, anything being sent from javascript can be tampered with. Cookies are always easy to replay (Who cares about forging them? Its just a random number.), and this doesn't matter as long as you use HTTPS. To be honest I don't think that this security system addresses CSRF at all, in fact I'm not sure what you are trying to protect against. It doesn't matter where your .lasso files are or what they contain.
What matters is the GET and POST requests can be forged. The whole point of having a CSRF token is that a 3rd party can't create an exact GET/POST request without knowing somthing about the site(and a simple token written as a hidden value works because of Same-Origin Policy). Don't roll your own security system, pick a solution off of the Cross-Site Request Forgery Cheat Sheet.