On my ecommerce website, I am trying to implement exchange feature. The backend is done Cashify API. I take details of new item and exchange item and send that to Cashify.
My request is being intercepted and data being changed before sending to Cashify.
I thought of encrypting the data, but then I have send across the encryption key to Cashify to get the value decrypted.
Related
This is my current understanding of recaptcha (using v2 invisible)
We load the api.js script onto our site
We add data attributes to the button
User clicks button
A listener somewhere in the api.js script fires because it's listening for an event on a tag with those data attributes
This is where it gets fuzzy and I start guessing:
api.js gathers browsing info from the user's cookies and information about how they interacted with the site. Based on this it determines how likely you are are to be a bot and if you are below a certain threshold it gives you a test. Whether you pass the test then gets further factored into your score and all of that gets encoded into a token, which we receive in our callback that we specified on the button's data attribute.
We pass this token to the back end with the rest of our form
From the backend, we make an API request to Google to convert the token into usable information about whether the user passed or failed.
At this point I get confused about why this wasn't just what the api.js script returned in the first place. Does this step only exist in order to give Recaptcha information to further improve it? I just don't understand why this step is here, unless I'm misunderstanding what is going on earlier in the process. Am I getting these we steps wrong? Thanks.
The whole point for captchas is that your server (instead of client in the browser) can verify that the (HTTP) request it received was generated from a real person's actions, when interacting with your application.
This is why your client sends a recaptcha token to your server and your backend consults with the captcha provider about this token and receives trusted information about the original client. In this scenario, your server does not trust the client, so it receives only a token from it. Then it communicates with the trusted captcha provider server-to-server and validates that the token it received from the client is valid and the user behind it is legitimate.
If your client sent the original response from the captcha provider to your backend server, there would be no way for your server to know whether this was a legitimate response from the captcha provider, or a fake one from the client.
I am using MEAN stack for developing a web application. I choose it be completely RESTFULL that is stateless. For authentication I am using JWT(Json Web Token) strategy.
Client sends login request to server, server authenticates and sends JWT and user data to the client(here angular 2).I am storing this JWT token in the cookie.
Now my question is how do we store/display user details in the view continuously. For eg if we consider Facebook as restful , after a user logs in, client display user data such as profile image, profile link etc etc.
Since Rest Authentication just retrieves the data, with credentials sent in each request.
How are these user related data retained in the client side. Is it like for each request, user data is fetched from the server and updated continuously in the view.
If yes how or if no then am I missing something.
I know this question might be nonsense to experts, but any advice, suggestion or kickstarter information would be helpful for a novice like me.Are there any best practises for these?
Thanks in advance
Yes, you can fetch user data from server on every request but the right approach is to store it in JWT token as custom claims and on each request get the token from cookie, decode it and get the necessary details from those custom claims.
By the way, you can store user data in localStorage for frequent use.
I am about to start working on a project, which is basically a web interface for a mobile banking application. The API is ready, I only need to provide the frontend part of the web application. I was going to make it using Backbone/Angular/Ember, but started to worry about the security.
Particularly, the following. As a rule, every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key. If I put the logic of how this param is calculated into one of .js files, anyone could potentially access some sensitive data using tools like Postman or even browser console. How should I go about this issue? I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key
I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
Yes, the server-side script would be the way to go if you do not want to expose the secret API key within your client side code or request data.
User token can (presumably) come from the user's session cookie value? So simply have a server side method that takes the method name and then returns the method_code calculated from the secret API key (kept server side only) and the user token.
The Same Origin Policy will prevent another domain making a request to your API and retreiving the method_code. I'm also assuming the API and front-end code runs on the same domain here, although if this is not the case you can use CORS to allow your front-end code to read and retreive data client-side via the API.
You can try to generate a token based on security factors and encrypt that and use it in your requests to identify your clients and valid requests.
We are building system that required login information for all pages. the application is designed to be Restful application using codeigniter as Phil Sturgeon library. This library is using API Key only to authorize api calls via sending it with every request over HTTPS connection.
Even if it using 2 way authentication or only API Key. What i am searching for a while is the following scenario:
User request the application for the first time (ex: https://www.xyz.com) then it will be redirected to the login page to check credentials
User enter the usernam/password and sent it via POST over the https
Server check if the information is valid then:
API KEY should be provided by the server to the client as a resource identified by this username (Here is the question???!!!)
How to send the API Key to the client in a secure way?
1) Could i use session-cookies and restore the API KEY in a cookie then use this API KEY on every coming request (This is violent the Stateless of the Rest and i don't sure if it securely enough).
2) Actually i don't know other options :) it's your turn if you could help
If you could give an example it would be a great help as i found and read lots of articles
:)
Since the connection is HTTPS, anything you send over the wire is secure (theoretically and provided you aren't being mitm'd). Not sure if the whole API is served over HTTPS (you didn't specify), so even though you could return the key as part of the login (while still under the umbrella of HTTPS), if the rest of the api isn't HTTPS, the key could be sniffed on the next request.
Sessions and cookies aren't typically part of a RESTful application; REST is stateless.
Something like a revolving key would be better for non-HTTPS (would work with HTTPS too). You login via HTTPS, server returns the api key, you use it on the next request, server returns new api key, you use it on the next request and so on. While it's better than a single api key over non-HTTPS, it's not perfect. If someone sniffs the response from one of the subsequent requests and you don't end up consuming that key, they can use it. This shrinks the attack vector to a non-HTTPS response from server to client since if a request from client to server is sniffed, the api key will have already been consumed by your legitimate request. However, more should be done to secure the api if you aren't serving it over HTTPS.
If it were me, I'd look into request signing + https. There's some talk of request signing here: https://stackoverflow.com/a/8567909/183254
There's also some info on digest auth at the Securing the API section of http://net.tutsplus.com/tutorials/php/working-with-restful-services-in-codeigniter-2/
A pseudo-code example js function on the client
function get_calendar(){
var key = $('#api_key').value();
$.ajax({
type: 'get',
url: '/index.php/api/calendar?key=' + key,
success: function(response){
// show calendar
// ...
// set received api key in hidden field with id api_key
$('#api_key').value(response.api_key)
}
})
}
Example controller method:
function calendar_get($api_key = ''){
if($api_key_matches){//verify incoming api key
$r = array();
$r['calendar'] = $this->some_model->get_calendar();
$r['api_key'] = $this->_generate_api_key();// generate or get api key
}
$this->response($r);
}
i have a question if using SSL will encrypt both the query string and the Post request body which contain the fields values ?
and if the answer is yes,,
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
BR
Then does this mean that i can be 99% confidence than an attaker will not be able to modify both the query string & the post body request?
SSL only encrypts and hide the information from a third party. However the hackers own request he can do whatever he wants with them, even if they are sent encrypted. As I said SSL only protects against a third party, not anything else.
A golden rule in all web development is, NEVER trust input data, Encrypted or not.
even if the attacker is Authenticated using a username and password to my web site.
The hacker can send whatever he see fit to the server, his request will be encrypted and protected against a third party, but he can send just whatever he want and your code, if you do not folow the line of never trust input data, he might breach into your server yeah.
So yet again SSL ONLY protects against a third party ( and even that some times not )
If you're using SSL, then yes, you can be sure an attacker will not be able to modify the query string or post data. SSL authenticates the server to the client to prevent anyone successfully impersonating your server. It also encrypts each message sent back and forth using the server's private X.509 key, so that no intermediary can decipher them.