I'm currently developing an application where holders can see historical data of their NFT's. All code is in place, but I'm still looking for a way to securely verify their ownership of a certain NFT.
There is the possibility to extend one of the dApp examples in the Elrond docs, but I'm not that familiair to React or NodeJS, so I'm trying to build this in PHP.
One thing I came across, is the login via Hooks, as used by the Maiar Exchange.
https://docs.elrond.com/wallet/webhooks/#login-hook
However, the Callback URL can be accessed manually by users, so this can give people Unauthorized access to my application.
Now, there is an undocumented extra parameter token I can pass to the Login hook (as used by Maiar Exchange). I know I can fetch a valid token by sending a POST request to 'https://id.maiar.com/api/v1/login/init'. This will give back a token I can append to the Callback URL. By doing so, the Callback URL will receive an appended signature parameter. I feel like I'm almost there, but the question is: How can I interpret this signature and how can I use this signature to verify if the returned response was valid and belongs to the given token/address? How was this signature is generated?
Also, I feel like it would be very nice if there was some sort of OAuth implementation for Elrond, but since it isn't there, I'm trying this approach.
I need to authenticate a webhook post from a third party integration on my backend api server. The only thing I can define is the endpoint url they will call. It can't be dynamic once they have to register and the process takes 3 days. And we use a multi-tenant solution, so we have to authenticate with different schema on every call.
So the problem is that I have to create a filter for this webhook, so I can authenticate it through a value contained in the json of a post body.
So I defined a WebSecurityConfigurerAdapter and added a AbstractPreAuthenticatedProcessingFilter so I can intercept the request, read the value in the json body authenticated with the appropriate credentials.
I follow this tutorial Reading HttpServletRequest Multiple Times in Spring so I could be able to read InputStream from the request without erase it.
So my question about it are two.
1: Is there a better/easy approach so I can archive this result?
2: I guess this tutorial are missing something, because I'm getting null pointer at servlet when try to read the request (again, after I have already read at the filter).
Any guess would be appreciated, thanks in advance.
Are we allowed to know which 3rd party service?
PayPal/Stripe for example have docs already to explain how to verify the data.
If you can add metadata/custom fields to the webhook, you could sign it for example.
As far as checking the signature/verifying it, why not do this in the #Contoller=>#Service?
I have a public website running from an eXist app. I am now developing an interface for logged in users to edit certain documents through HTML forms and AJAX. I've set up a module in eXist to receive AJAX POST requests through the eXist REST interface (ie. http://www.example.com/exist/rest/db/myapp/api/myxquery.xql). However this module does not seem to be aware of the fact that the user is already logged in!
How do I get the REST module to use the session/authentication of the logged in user?
Am I required to store the user/password in the browser to pass with each REST API request?
If this is not the preferred model for passing data from the browser under user/password, what is eXist's recommended solution?
Many thanks in advance.
(A variation on this question was asked two years ago but received no solutions.)
In order to use the REST-API from existdb you can only authenticate each request using HTTP Basic Authentication. Also mentioned in the question you referenced.
If you decide to handle AJAX request in your app's controller.xql you will need to:
Add routes for your AJAX requests to the controller
Make sure you call login:set-user for the user session to be picked up
Make sure the AJAX request sends the cookie:
For instance, the fetch function will send the authorisation cookie
only if send-authorization is true.
Look at the output-method and serialization settings, since you will likely want to respond in JSON-format. useful blog post about this
Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.
I want to use post to update a database and don't want people doing it manually, i.e., it should only be possible through AJAX in a client. Is there some well known cryptographic trick to use in this scenario?
Say I'm issuing a GET request to insert a new user into my database at site.com/adduser/<userid>. Someone could overpopulate my database by issuing fake requests.
There is no way to avoid forged requests in this case, as the client browser already has everything necessary to make the request; it is only a matter of some debugging for a malicious user to figure out how to make arbitrary requests to your backend, and probably even using your own code to make it easier. You don't need "cryptographic tricks", you need only obfuscation, and that will only make forging a bit inconvenient, but still not impossible.
It can be achieved.
Whenever you render a page which is supposed to make such request. Generate a random token and store it in session (for authenticated user) or database (in case this request is publicly allowed).
and instead of calling site.com/adduser/<userid> call site.com/adduser/<userid>/<token>
whenever you receive such request if the token is valid or not (from session or database)
In case token is correct, process the request and remove used token from session / db
In case token is incorrect, reject the request.
I don't really need to restrict access to the server (although that would be great), I'm looking for a cryptographic trick that would allow the server to know when things are coming from the app and not forged by the user using a sniffed token.
You cannot do this. It's almost one of the fundamental problems with client/server applications. Here's why it doesn't work: Say you had a way for your client app to authenticate itself to the server - whether it's a secret password or some other method. The information that the app needs is necessarily accessible to the app (the password is hidden in there somewhere, or whatever). But because it runs on the user's computer, that means they also have access to this information: All they need is to look at the source, or the binary, or the network traffic between your app and the server, and eventually they will figure out the mechanism by which your app authenticates, and replicate it. Maybe they'll even copy it. Maybe they'll write a clever hack to make your app do the heavy lifting (You can always just send fake user input to the app). But no matter how, they've got all the information required, and there is no way to stop them from having it that wouldn't also stop your app from having it.
Prevent Direct Access To File Called By ajax Function seems to address the question.
You can (among other solutions, I'm sure)...
use session management (log in to create a session);
send a unique key to the client which needs to be returned before it expires (can't
be re-used, and can't be stored for use later on);
and/or set headers as in the linked answer.
But anything can be spoofed if people try hard enough. The only completely secure system is one which no-one can access at all.
This is the same problem as CSRF - and the solution is the same: use a token in the AJAX request which you've perviously stored eslewhere (or can regenerate, e.g. by encrypting the parameters using the sessin id as a key). Chriss Shiflett has some sensible notes on this, and there's an OWASP project for detecting CSRF with PHP
This is some authorization issue: only authorized requests should result in the creation of a new user. So when receiving such a request, your sever needs to check whether it’s from a client that is authorized to create new users.
Now the main issue is how to decide what request is authorized. In most cases, this is done via user roles and/or some ticketing system. With user roles, you’ll have additional problems to solve like user identification and user authentication. But if that is already solved, you can easily map the users onto roles like Alice is an admin and Bob is a regular user and only admins are authorized to create new users.
It works like any other web page: login authentication, check the referrer.
The solution is adding the bold line to ajax requests. Also you should look to basic authentication, this will not be the only protector. You can catch the incomes with these code from your ajax page
Ajax Call
function callit()
{
if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}
xmlhttp.onreadystatechange=function(){if(xmlhttp.readyState==4&&xmlhttp.status==200){document.getElementById('alp').innerHTML=xmlhttp.responseText;}}
xmlhttp.open("get", "call.asp", true);
**xmlhttp.setRequestHeader("X-Requested-With","XMLHttpRequest");**
xmlhttp.send();
}
PHP/ASP Requested Page Answer
ASP
If Request.ServerVariables("HTTP_X-Requested-With") = "XMLHttpRequest" Then
'Do stuff
Else
'Kill it
End If
PHP
if( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) && ( $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ) )
{
//Do stuff
} else {
//Kill it
}