The problem i am facing is that clicking on F12 on Chrome Browser , i could see all the Rest Calls which are made to fetch the data
For example , one of the REST API call is
(When clicked on the above link , it fetches the data )
This is my front code consists of Jquery
function displaymarketupdates() {
var updatedon = "";
var html = '';
var t = "",
$.ajax({
type: "GET",
url: e,
crossDomain: !0,
dataType: "json",
timeout: 17e3,
async: !0,
cacheResults: !1,
cache: !1,
contentType: "application/json",
charset: "utf-8",
beforeSend: function() {
$(".loadingWrapformarketupdates").show()
},
complete: function() {
$(".loadingWrapformarketupdates").hide()
},
success: function(response) {
},
error: function(t, e, a) {
$(".loadingWrapformarketupdates").hide()
}
}).done(function() {
})
}
And this is my service
#Path("/fetchallvalues")
public class FetchAllValues {
public FetchAllValues() {}
private final static Logger logger = Logger.getLogger(FetchAllValues.class);
#GET#Produces("text/plain")
public Response Fetch_all_values() {
PreparedStatement fetch_all_pstmt = null;
ResultSet fetch_all_Rset = null;
Connection dbConnection = null;
ResponseBuilder builder = Response.status(Status.NOT_FOUND);
final JSONArray fetch_array = new JSONArray();
final String inputsql = "select * from all_values";
try {
dbConnection = DBConnection.getDBConnection();
fetch_all_pstmt = dbConnection.prepareStatement(inputsql);
fetch_all_Rset = fetch_all_pstmt.executeQuery();
while (fetch_all_Rset.next()) {
====
}
Response.status(Status.OK);
builder = Response.ok(fetch_array.toString());
} catch (Exception e) {
e.printStackTrace();
logger.error("Error description", e);
} finally {
try {
DBConnection.close(fetch_all_pstmt, fetch_all_Rset);
} catch (Exception e) {
logger.error("Error description", e);
}
try {
DBConnection.close(dbConnection);
} catch (Exception e) {
logger.error("Error description", e);
}
}
return builder.build();
}
}
Could you please let me know how to secure the REST CALL in this case
You cannot hide an URL from a Browser's network monitoring. It is meant to be displayed so that it can be inferred that what is happening when you hit a button or click something.
Securing a REST Jersey call is a totally different thing. That means you do not want people to see your data that you are going to pass. As correctly mentioned by Martingreber that if you call this URL on HTTPS that may help you encrypt data that you send across the servers. Or securing a REST call actually means you provide some kind of authentication to it . Like Basic , Hashing like MD5, Token based Authentication like JWT.
The only thing that you can do to hide explicit details from your browser that runs your JavaScript is minify your script . But still your URL remains exposed as many times as it is called by someone who fiddles with the F12 key on Chrome to see what's going on. One more thing can be if you are concerned about your main service call, and don't want to expose that , then just PROXY it using some service, which you are already doing . But by no means, you can avoid your URL being getting displayed, when someone calls it.
In your case fetchAllValues service is fetching the data and exposing it to anybody on the web who clicks it, but that can be prevented if you authenticate the service, like the minute i click that URL, it asks me for a password! Then i cannot access it. A very simple way to authenticate this service would to call a Filter or an Interceptor just before the request to ask for username and password like credentials.
I hope you got the point. Hope this helps :)
You will always be able to see the URL that is being processed. Still, you could obfuscate the Service Endpoint to hide the purpose of the service itself, e.g. #Path("/XYZ")instead of #Path("fetchallvalues")
If you want to hide the data that is being transmitted between the client and the server, so noone can read it, simply use https. Depending on your webserver (Jetty, Tomcat) you will have to configure it differently, still you will need a ssl certificate for your domain, which you can get here for example: https://letsencrypt.org
If you want to secure your webservice, so it can't be used by anyone, but only by specific users, you might want to give Spring Security a try: User authentication on a Jersey REST service
This is a problem that needs some smart hacks to fix it.
In the hyperlinked stackoverflow page, you will get an example of how to make a SOAP request from client side JavaScript.
SOAP request from JavaScript
Now here's the plan:
In the server side, we have a random number generator, which generates a random number in short intervals, say 5 minutes.
The random number generator will be exposed as a SOAP service and it will produce the random number generated.
From the client side, we will invoke the SOAP random generator service (refering to the stackoverflow page mentioned above) and get the generated random number as the response. We will invoke the service from a JS function which will be fired when your page is loaded (onLoad). So, now we have the random number at the client side.
Then, we pass the random number as a path param in the GET request URL of the REST call and fire the GET request.
In the server side, once the Rest GET request is received, we check if the number received as path param is the same number that is generated in the server side.
If the numbers match, then we give the required response, else do not send the response.
Here we are trying to introduce an unique key, which is the random number generated at the server side. This unique key, when passed as the path param of the Rest GET request URL, serves as an identity of the origin of the Rest GET call. For someone who wants to invoke the Rest Api by referring to the Network Tab of the Chrome Dev console, will not get the unique key for a long time ( as it is refreshed/regenerated after every 5 minutes). Thus the hacker will not be able to use the Rest Api for a long duration. Also, since we are transporting the unique key (the random number) from the server to client side using SOAP, it is not possible for the hacker to get it from the Chrome's developer console.
Hope this approach helps!
Unfortunately, there is nothing you can do to prevent the client from inspecting the requested URL. But you always can require credentials to access your API endpoints.
Authentication in REST APIs
In REST applications, each request from the client to the server must contain all the necessary information to be understood by the server. With it, you are not depending on any session context stored on the server and you do not break the REST stateless constraint, defined by Roy Thomas Fielding in his dissertation:
5.1.3 Stateless
[...] communication must be stateless in nature [...], such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]
When accessing protected resources (endpoints that require authentication), every request must contain all necessary data to be properly authenticated/authorized. And authentication data should belong to the standard HTTP Authorization header. From the RFC 7235:
4.2. Authorization
The Authorization header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested. [...]
In other words, the authentication will be performed for each request.
Basic authentication
The Basic Authentication scheme, defined in the RFC 7617, is a good start for securing a REST API:
2. The 'Basic' Authentication Scheme
The Basic authentication scheme is based on the model that the client
needs to authenticate itself with a user-id and a password for each
protection space ("realm"). [...] The server will service the request only if it can validate
the user-id and password for the protection space applying to the
requested resource.
[...]
To receive authorization, the client
obtains the user-id and password from the user,
constructs the user-pass by concatenating the user-id, a single
colon (":") character, and the password,
encodes the user-pass into an octet sequence,
and obtains the basic-credentials by encoding this octet sequence
using Base64 into a sequence of US-ASCII
characters.
[...]
If the user agent wishes to send the user-id "Aladdin" and password
"open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
[...]
Token-based authentication
If you don't want to send the username and the password over the wire for every request, you could consider using a token-based authentication. In this approach, you exchange your hard credentials (username and password) for a token which the client must send to the server in each request:
The client sends their credentials (username and password) to the server.
The server authenticates the credentials and generates a token.
The server stores the previously generated token in some storage along with the user identifier and an expiration date.
The server sends the generated token to the client.
In every request, the client sends the token to the server.
The server, in each request, extracts the token from the incoming request. With the token, the server looks up the user details to perform authentication and authorization.
If the token is valid, the server accepts the request.
If the token is invalid, the server refuses the request.
The server can provide an endpoint to refresh tokens.
Again, the authentication must be performed for every request.
The token can be opaque (which reveals no details other than the value itself, like a random string) or can be self-contained (like JSON Web Token).
Random String: A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web Token (JWT): Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server. You won't need to persist JWT tokens if you don't need to track them. Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To find some great resources to work with JWT, have a look at http://jwt.io.
In a token-based authentication, tokens are your credentials. So the tokens should be sent to the server in the standard HTTP Authorization header as described above.
Once you are using Jersey, you could have a look at this answer for more details on how to implement a token-based authentication in Jersey.
HTTPS
When sending sensitive data over the wire, your best friend is HTTPS and it protects your application against the man-in-the-middle attack.
To use HTTPS, you need a certificate issued by a certificate authority such as Let’s Encrypt, that claims to be a free, automated, and open certificate authority.
I am new to backbone.js. I built a rest api with php and I want to connect to it with backbone.js. I am having a tough time with passing the http basic auth that my rest api uses for authentication.
I can access my rest api easily by using curl from the command line like this
curl -u username:password -X GET http://api.mysite.com/user
But when I try to do a fetch (which is pretty much all I am trying to do) I get a response from my rest api that the authentication failed.
Here is my call from backbone.js
user.fetch({headers:{'Authorization':'Basic username:password'}});
With backbone.js I am getting back the response I would expect when the basic auth fails. My question is, since I know my rest api with authenticate with curl, why won't it authenticate with the above javascript?
Also, when I look at the headers sent in the js console I don't see anything about Authorization.
UPDATE
I tried the plugin listed in the comment below but got the same result
Here is my code
var User=Backbone.Model.extend({
url: 'http://api.mysite.com/user'
});
var user=new User();
user.credentials = {
username: 'username',
password: 'password'
};
user.fetch();
The username and password need to be encoded with Baes64 before being sent.
One easy way to do this (at least for testing) is to configure all jQuery ajax requests to send the info (Backbone uses jQuery for the ajax calls):
$.ajaxSetup(
beforeSend: function(xhr){
xhr.setRequestHeader("Authorization", "Basic " + btoa("USERNAME" + ":" + "PASSWORD"));
}
);
Note that btoa is the function that will encode the params with Base64. Now you can call user.fetch() and it should work properly: you don't need to provide the credentials, because we've configured jQuery to send them for us (all the time).
Of course, depending on your situation (e.g. using multiple APIs), you might prefer to specify the beforeSend attribute within each request, or have it defined within a Backbone syncfunction.
I added "Authorization" to the allowed headers list and that did the trick.
header("Access-Control-Allow-Headers: Authorization, Origin, X-Requested-With, Content-Type, Accept");
I have been using FB api for some simple demo and everything was quite easy with the authentication. Now I have to do something similar with twitter v1.1 but there is something that I really don't understand...
Example:
I want to do this request:
https://api.twitter.com/1.1/search/tweets.json?q=q=%23freebandnames
the problem is that I have to be authenticated, anyone have some examples? I don't want to create a twitter connection because I don't need different users to be connected to my applicaiton. I have just to perform some simple search request but I can't understand how to use the authentication parameters. Which type of Ajax request I have to use in order to perform the REST request authenticated??? (Obviously I have my secret token and my access secret token) but how to use them????
THanks in advance for answers
You can use this javascript library: codebird-js with the "Application-only auth".
or
Do it yourself: everything is explained in the documentation.
Basically you need to follow 3 steps (and you should do the 2 first just once):
An application encodes its consumer key and secret into a specially encoded set of credentials.
An application makes a request to the POST oauth2/token endpoint to exchange these credentials for a bearer token.
When accessing the REST API, the application uses the bearer token to authenticate.
The steps are detailed in the documentation.
You can do the first 2 separately and when you get your bearer token, you need to add a specific HTTP Header (Authorization) in each request with your bearer token (that's the 3rd step). With jQuery it could be something like that:
$.ajax({
headers: { Authorization: 'Bearer '+$my_bearer_token },
url: 'https://api.twitter.com/1.1/search/tweets.json?q='+$search
}).done(function (data) {
// Play with the data
});
I am trying to access a REST web service using HTTP GET request.
For a example following URI provides Rest web service that return all the available parts for the given category.
http://localhost:8080/mycompany/parts/category
I want to authenticate/authorize users who are accessing above REST request in each time and I want to pass User authentication details (User Name and Token) with the HTTP Get Request.
Is there a possibility to cater to the above requirement in REST HTTP GET request (using HTTP header or query parameters)?
or
Is it better to use HTTP POST instead of HTTP GET?
Since you are getting information, you should use "Get". Here's the code that I use (it is Restlet based) for adding the oauth_token to the request...
import org.restlet.data.Reference;
import org.restlet.ext.oauth.OAuthUser;
import org.restlet.representation.Representation;
import org.restlet.resource.ClientResource;
Reference commitsRef = new Reference(Consts.RESOURCE_BASE + "commitments/");
OAuthUser u = (OAuthUser) request.getClientInfo().getUser();
String token = u.getAccessToken();
ref.addQueryParameter("oauth_token", token);
ClientResource commitsResource = new ClientResource(getContext(), commitsRef);
Representation commitsRep = commitsResource.get();
As mentioned, this is Restlet based, but there is probably something similar in the framework you are using. (And if you are not using a framework, Restlet can make this easier).
if you are using restlet than good because restlet have rich api for rest framework
but without this if you want to authenticate than
you can do same thing with GET or POST
but send your credential data trough cookie
and read same cookie using #CookieParam from server side
in this way you can easily authenticate user.
I want users to be able to log in via HTTP Basic authentication modes.
The problem is that I also want them to be able to log out again - weirdly browsers just don't seem to support that.
This is considered to be a social-hacking risk - user leaves their machine unlocked and their browser open and someone else can easily visit the site as them. Note that just closing the browser-tab is not enough to reset the token, so it could be an easy thing for users to miss.
So I've come up with a workaround, but it's a total cludge:
1) Redirect them to a Logoff page
2) On that page fire a script to ajax load another page with dummy credentials:
$j.ajax({
url: '<%:Url.Action("LogOff401", new { id = random })%>',
type: 'POST',
username: '<%:random%>',
password: '<%:random%>',
success: function () { alert('logged off'); }
});
3) That should always return 401 the first time (to force the new credentials to be passed) and then only accept the dummy credentials:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult LogOff401(string id)
{
// if we've been passed HTTP authorisation
string httpAuth = this.Request.Headers["Authorization"];
if (!string.IsNullOrEmpty(httpAuth) &&
httpAuth.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
{
// build the string we expect - don't allow regular users to pass
byte[] enc = Encoding.UTF8.GetBytes(id + ':' + id);
string expected = "basic " + Convert.ToBase64String(enc);
if (string.Equals(httpAuth, expected, StringComparison.OrdinalIgnoreCase))
{
return Content("You are logged out.");
}
}
// return a request for an HTTP basic auth token, this will cause XmlHttp to pass the new header
this.Response.StatusCode = 401;
this.Response.StatusDescription = "Unauthorized";
this.Response.AppendHeader("WWW-Authenticate", "basic realm=\"My Realm\"");
return Content("Force AJAX component to sent header");
}
4) Now the random string credentials have been accepted and cached by the browser instead. When they visit another page it will try to use them, fail, and then prompt for the right ones.
Note that my code examples are using jQuery and ASP.Net MVC, but the same thing should be possible with any technology stack.
There's another way to do this in IE6 and above:
document.execCommand("ClearAuthenticationCache");
However that clears all authentication - they log out of my site and they're logged out of their e-mail too. So that's out.
Is there any better way to do this?
I've seen other questions on this, but they're 2 years old - is there any better way now in IE9, FX4, Chrome etc?
If there is no better way to do this can this cludge be relied upon? Is there any way to make it more robust?
The short anser is:
There is no reliable procedure for achieving a "logoff" using
HTTP Basic or Digest authentication given current implemenations of basic auth.
Such authentication works by having the client add an Authorization header
to the request.
If for a certain resource the server is not satisfied with the credentials provided (e.g. if there are none), it will responde with a
"401 Unauthorized" status code and request authentication. For that purpose it will provide a WWW-Authenticate header with the response.
A client need not wait for a server requesting authentication.
It may simply provide an Authorization header based on some local
assumptions (e.g. cached information from the last successful attempt).
While your outlined approach on "clearing" out authentication info has a good chance of working with a wide range of clients (namely widespread browsers),
there is absolutely no guarantee that a nother client might be "smarter" and
simply discriminate proper authentication data for your "logout" page and any other pages of the target site.
You will recognize a similar "problem" with using client side certificate based authentication.
As long as there is no explicit support from clients you might fight on lost ground.
So, if "logoff" is a concern, move over to any session based authentication.
If you have access to the implementation of authentication on the server side you might be able implementing a functionality that will disregard authentication information presented with Authorization header (if still identical to what has been presented during current "session) on request of your application level code (or provide some "timout" after which any credentials will be re-requested), so that the client will ask the user for providing "new" credentials (performing a new login).