I have a question about an issue with sending Data to my Database. I’m looking for a secure way to bring sensitive data such as ingame credits or Hwid's or Something like that in a database. So I thought I could use the unity’s WWWFORM with the post method but I have the fear that it is not secure because anyone could send something to the server using the Post method, or somebody could spam my Database server with requests and maybe hack my server. Maybe I thought of a secret key (token) to verify that it is my game that sends the data. However, if someone decompiles my game, then he can see the token and can also send data to my server. Do any of you know of a secure way to send data securely to the server without anyone being able to modify the data along the way or have access to the database?
Related
I'm making an application with Express and Angular and I want to ask where to keep the results of mongoose queries for Angular to display them.
Here's the idea of my app
1) User logs in, gets authenticated
2) Once authenticated, the server gets the details of the user via mongoose
3) The server sends it to Angular to display it by storing the details in a cookie.
4) Angular accesses the cookie, gets the data inside it and displays it in the template.
My question is, is that the correct way of doing it? Another way I can think of is sending it as a json for Angular to get it ($http.get([url with json data]).then(displayData))
So in short
1) Is it okay or safe in saving the data in a cookie?
2) Are there other ways to do it?
I'm sorry if it comes of as very noobish. I have seen questions regarding sending data from Angular to Node but nothing about Node to Angular.
Note: Using Angular 1.x
To undertake the operations that you have listed you can use broadly two approaches, one is mongoose sessions with express sessions and another one is to use JSON Web tokens (JWT). And both are secure way of storing and communicating with the server. Only difference is that while using sessions we store the data in the server and the client just gets a session ID through which the server can uniquely identify the user session.But while using JSON web tokens we will have an encrypted token that can be decrypted in the server and then access the needed information
So the answer to the first question. Is it safe to store the data in a cookie? YES!
Is there any other way to do it? YES You can use JSON web tokens to communicate with the server. though it takes a bit of a different approach.
Either way both are secure way of commnicating with the server. It all depends on how you want to set the server up. Good luck :)
Do you know of any payment solution for React that don't require any backend? I've tried implementing Noodlio as it said that it would work for React. I could not find any projects using react and Noodlio and I didn't get it to work.
So:
has anyone gotten Noodlio to work with React and are willing to tell me how?
Or are there any other payment solution that doesn't need a server?
Payments are Exactly Transferring Money Or Giving Credit from One Client to Another.
Credit Amount Have to be save in some place.
Client-side is not a good field for this work because the receiver should trust the sender and sender always could get offline and get unreliable ....
so there need for an back-end which has to be:
always accessible (online)
trust able by a wide range of people
but this criteria can be made via 2 approaches:
centralized : which needs a server which perform payment action and client would communicate with APIs.
decentralized : client sending payments to miners to approve. (in this case there is no need for you to implement backend)
The Most Security issue that concerns client is how to avoid account hijacking:
in centralized : client should transfer sensitive data securely and saving no tokens/ password in client system.
in decentralized: client shouldn't save any private key or backup phrases in client side. every other aspects are secure via blockchain back-end.
for a successful only Client Implementation Payment Solution, i
recommend you to use Cryptocurrency blockchains as a backend.
I have the following code in my angular app declaration - an API key for Facebook (to implement Share button):
.run(function($FB){
$FB.init('9xxxxxxxxxxxx94');
})
So i know the general answer to this - 'API keys should be kept on the server side', however I don't see how i actually implement this.
The share call-method is made on the front end, so even if my server kept the API key and sent it, surely it's still visible on the front end, else how would the share button work?
So my question, how do I hide that Facebook API Key?
Thanks.
Requesting the key
The first thing that happens is that the client will request a key. This will only happen on certain pages like the sign up and log in pages. The idea here is that we want to make sure that only users browsing with a known client (in this case the official website or core client as it’s called) are allowed to take actions like creating or authenticating a user.
So when the client app requests the login page the server generates a unique token based on information sent in the request. The information used is always something the server knows, something the client knows, and something both know. So for example the server can generate a unique key based on User agent + current time + secret key. The server generates a hash based on this information and then stores a cookie containing only the hash on the client machine.
Setting permissions
At this point our key really isn’t a key anymore. It has been transformed into an access token. The server should then take this access token and store it for later retrieval. You can put the key in a database but since data of this type needs to be retrieved often I would suggest using a key-value store like Redis to cut down on database reads/writes and boost performance.
When you store the token you should also store a separate piece of data to indicate what permissions are associated with the token. In this case our token is acting only as a way to register and authenticate users so we store it next to a value that indicates who the token belongs to (the app’s web UI) and what permissions it has (limited to create and authenticate users). We treat it just like we would any other API client that way we can capture stats and control how it is used.
Authorizing a request
When the client then makes the POST request to create a new user or log in the server will check to see if the client sent an identifying cookie along with the request. If not, we reject the request. If it does send the cookie, the server should once again generate the hash using the values used previously (these values are either already known or sent with the request anyway so we’re not really taxing the server much) compare it to the cookie being sent to us, and if the values match allow the request to proceed.
Sources - Securing API Keys
OR
Simply send a request to your Server and let him handle your request with the hidden API-key and just return the result of your request to your front-end.
I am creating an Angular application, and I am having trouble wrapping my head around the proper way to ensure my application and its users is secure.
I've been reading around many stack discussions, but I believe I am missing some core understanding of what is happening, please correct any errors you see written below.
So far I have a Sinatra server with many (currently mostly hypothetical) resource routes. A user can create an account using an email address and password that is stored in a database after being hashed with BCrypt. When a user logs in, the record is retrieved from the database by email and the password checked for authentication. It is from this point I am not sure how to proceed.
Prior to this I have simply set a session variable and had the server check that the variable exists in order to correctly route logged in users. Now my application is (currently) a single HTML page that uses Angular and ui-router to display different content, so most of the requests are simply returning JSON content.
It is my understanding that Restful applications should generally not use sessions, or rather that the server should respond identically to identical requests and not have its own data that shapes a response. But if I do not store something in a session variable, how could the server know that the client making the request has the correct permissions? And are sessions not stored in the browser anyway, thus not part of the server?
I believe from what I have read, it is possible to create a token which is essentially a large random string, return that string to the client and also store it in a database with a timestamp. The client then provides this token when making requests and the server hits the database to verify it exists and valid. But would the client not also have to store that string in a cookie? I suppose the angular application could store the token in a variable, which would persist while using the ui-router but not if the users navigates using the address bar.
I also do not understand how Basic Auth may or may not fit into this picture. Any help would be greatly appreciated, as well as a pointer to some good resources where I may find a better understanding of these concepts in general.
You want to read up on JWT. There are JWT libraries for Ruby and Angular.
I know you aren't using Node for your backend but a very easy way to see all the pieces working together is to run the angular-fullstack Yeoman generator. It uses JWT and the code is easy to follow.
As far as I can see, whatever you are doing with your sessions can work just fine.
This can be a sample JSON response from the server in case the user is not loged in :
{
"errorCode": 1,
"error": "User not logged in",
"data": {}
}
You can set your own error codes and handle what you want to do. You will send any data only if the user is logged in. For all the pages which don't require authentication, you can set data to whatever you want.
On the angularJS side, you can handle based on error codes, you can redirect the user to the login page and so forth.
The alternate way to support the same on multiple platforms is to use token based approach. The token based approach in simple words work this way.
The user logs in for the first time with his / her credentials.
The server verifies these information and creates a token from which the server is able to decode the user id.
Whenever the client makes the requests, it passes its token with every request.
As the server can decode the user information from the token, it sends or doesn't send the data based on whether that's a right token or not.
The token depends on a secret value. It can be same for all the users or differnet for each based on how you want to implement.
This is all done and you can look at
http://jwt.io/
As #andy-gaskell mentioned, you can look at
http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
I'm very bad at explaining. Please let me know if any of this doesn't make sense.
you are missing the point of the REST concept. One of the main concepts in the REST apis is that the server should be stateless - this means that you should not store sessions or other "state" in your web server. Every HTTP request happens in complete isolation. Every request should include all data needed by the server to fulfill the request.
But if I do not store something in a session variable, how could the
server know that the client making the request has the correct
permissions?
You can store request scoped variables. This means that they should be only active during the same request. You can store the current logged in user in the request scoped variable. In that way you can get the current user in your invocation of the business method. I'm not familiar with Sinatra but here is the doc: http://www.sinatrarb.com/intro.html#Request/Instance%20Scope
But would the client not also have to store that string in a cookie?
of course you should store your access token in the client side
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
as #Andy Gaskell suggest take a look at JWT and fullstack application code generators and forget about the basic auth because it's really "basic".
more useful links:
If REST applications are supposed to be stateless, how do you manage sessions?
http://www.sitepoint.com/php-authorization-jwt-json-web-tokens/
How can I make sure the data I'm sending on a http request to a server was actually generated by my application (mobile application) and not handcrafted by the user?
For example: If I have a game and I want to submit the user's score to the server, how to make sure the user doesn't see the request data and start sending handcrafted scores to the server?
I thought about using a hash algorithm together with an app secret key. So the request would send four pieces of data: the score, the date, the userid and a hashed (score+date+userid+secret_key). Then, I could perform this hash operation again on the server and verify the data is legitimate. However, how can I protect myself from the case where the hacker is able do disassemble the application and see what the secret_key is?
Is there a better way to do this other than signing the request with a hash code?
Short answer, you can't. Anything the user can do through the application, they can do by reverse-engineering the application and doing what it would do. All you can do is make things harder for them.