I am looking at ways to implement a safe client-server communication via HTTPService requests in Flex/Air. The server side is implemented in PHP, whereas the client could be running on a desktop (Air) or on a browser (flex).
The simply usecase that I need help to secure is -
Desktop client sends a request to the server and gets a response
How can I ensure at the server side that the request is being sent from a valid client? From what I could research, Flex doesn't allow for manipulation of request headers so I am failing to manipulate them. All request queries can be seen by using any network monitor, so having a unique (yet static) parameter won't really hit what I am trying to achieve.
On the other hand, the server can be mimicked by simply manipulating the hosts file. At the client end, how can I ensure that I am receiving the response from the actual server and not from an alias added to hosts file
My solution is to encrypt and decrypt data on the both sides.
In the Air data you need to send should be encrypted with as3crypto and send to server where PHP whould decrypt it, Look here in the last post for the working code example decrypt a as3crypto encrypted text in PHP, you can do the same in case of server to client communation.
So you need to keep same Key and IV for both server and client sides, To be more secure you can embed them as binary data in the project http://www.ghostwire.com/blog/archives/as3-embedding-binary-xml/, it's wouldn't be easily viewable for AS3 decompilers, but anyway take for the notice that it might be hacked by the advanced guys.
Related
context
I'm building a project to better understand login/security, and SSL is really tripping me up.
So far I have a front end (vue.js), an API (node/express), and a DB (postgreSQL).
This is the general auth flow:
When a user logs in they send an email and password (via Axios) to the API.
The API queries the database for a matching username and then using bcrypt.compare it checks the password that is hashed in the database.
If this is successful, the API signs a JWT and sends it to the client.
The client then saves the JWT in local storage and is used for future queries.
question(s)
So far I think that all of the above is the best practice EXCEPT for the first step. From the reading, I've done so far the client needs SSL to securely send a password to the API. Is this the case? Does my server also need to be SSL or just the client/host?
I'm ultimately going to try to use firebase hosting (which is automatically SSL) for the frontend, and heroku for the API and database. If there are more secure options I'm open to suggestions.
Also, in general, I'm new to all of this security stuff - If I'm missing anything or if something else isn't secure, I would love the advice!
SSL creates a secure connection between two points. In our scenario between the client, and the server. After some initial negotiation, the client encrypts its messages in a way that only the server can decrypt. And the server does the same with its answers, or its own questions. By using SSL between these two end points, nobody but the client and server can read the messages.
This is important, since a message sent between client and server is actually seen by many more machines/processes in between. Dozens of other processes can thus see the message, and if the message is not encrypted that means all those processes can know exactly what's in the message. When the client and server communicate over SSL, the other processes still see the messages, but they can't decrypt them.
To your concrete questions: the client opens a secure connection to the server. Both the client and the server need to support this. If you write a custom server, that means you'll need to ensure it has a SSL certificate. A very common place to get these for free these days is letsencrypt.org.
I have a web-server with an SSL certificate, and an unsecured device on a GSM/GPRS network (arduino MKR GSM 1400). The MKR GSM 1400 library does not feature a SSL server, only an SSL Client. I would prefer to use a library if that's possible, but I don't wanna write a SSL Server class. I am considering writing my own protocol, but I'm familiar with HTTPS and will make writing the interface on the webserver side easier.
The GSM Server only has an SSL Client
I am in control of both devices
Commands are delivered by a text string
Only the webserver has SSL
My C skills are decent at best
I need the SSL Server to be able to send commands to the Arduino Device, but I want these commands to be secured (The arduino device opens and closes valves in a building).
The other option would maybe have some sort of PSK, but I wouldn't know where to start on that. Is there an easy function to encrypt and decrypt a "command string". I also don't want "attackers" to be sending commands that I've sent before.
My Basic question is, does this method provide some reasonable level of security? Or is there some way to do this that I'm not thinking of.
While in a perfect world there would be a better approach, you are currently working within the limits of what your tiny system provides.
In this situation I find your approach reasonable: the server simply tells the client using an insecure transport that there is some message awaiting (i.e. sends some trigger message, actual payload does not matter) and the client then retrieves the message using a transport which both protects the message against sniffing and modification and also makes sure that the message actually came from the server (i.e. authentication).
Since the trigger message from the server contains no actual payload (arrival of the message itself is enough payload) an attacker could not modify or fake the message to create insecure behavior in the client. The worst what could happen is that some attacker will either block the client from getting the trigger messages or that the attacker fakes trigger messages even though there is no actual command waiting from the server.
If the last case is seen as a problem it could be dealt with a rate limit, i.e. if server did not return any command although the client received a trigger message than the client will wait some minimum time before contacting the server again, no matter if a trigger message was received or not. The first case of the attacker being able to block messages from the server is harder to deal with since in this case the attacker is likely able to block further communication between client and server too - but this is a problem for any kind of communication between client and server.
My server send some data to the mobile app
The user does some operations with those data and sends other objects back to the server, which contains the data that the server first sent (PS: of course those objects are created by the mobile app through user interaction)
Before the server persist mobile's data, should I validate if the server data inside it is consistent? Because if it's not, it will cause a exception.
But if you know it will cause a exception, why don't you avoid it?
Because I'm relying on:
Mobile app to be working 100% and send consistent data
Authentication between requests so it's not forged
Extra overhead checking something that normally would be OK, unless someone hacks it
Yes, you should validate and sanitize all inputs on the server side. Authentication doesn't help with integrity. If I am an attacker, I can make HTTP requests using CURL bypassing any security control you may have in your app.
in noVNC there is a way to send a string from client to server using the api 'send_string' which is implemented inside websock.js, one thing i noticed is sending string this way is it is not RFB encoded(correct me if i am wrong), so the advantage in this case is commands can be send to intermediate proxy which intern connect to VNC server...
Now my query is .. is there a way for this intermediate proxy to send back some string back to vnc client... means it is not RFB encoded, so will be handled differently # client
Thanks in advance
The websock.js library is the client-side part of the websockify project. The purpose of websockify is to bridge between WebSockets (which are message based) and normal TCP sockets (which are stream based).
The API that websock.js presents is a streaming API rather than a message based one. In addition, websockify/websock.js enables sending/receiving of binary data to the remote target even if the older WebSocket protocol (Hixie) is used which does not natively support binary data.
The send_string function is a convenience function so that you don't have to convert a string to an array form of the data before sending it. The data is still sent to the final target (it is not intercepted by websockify). The beginning of the RFB handshake is string based and so noVNC uses send_string in a couple of places (again, as a convenience).
If you want to have out-of-band communication between websock.js and websockify then you will need to modify both sides, perhaps by adding an initial byte to every message that indicates whether it is out-of-band signalling or part of the in-band stream. It is not builtin functionality.
Disclaimer: I made noVNC and websockify.
Do I need to use a websocket to send JSON data to my client? (it's a tiny session description)
Currently my client-side code sends a session description via XHR to my Node.js server. After receipt, my node server needs to send this down to the other client in the 'room'.
I can achieve this using socket.io, but is it possible to do anything a bit faster/ more secure, like XHR for example?
If you just want to receive the offer from the other side and nothing else, I would suggest you to try HTML5 Server Sent Events.
But this may bring problems due to different browsers support, so I would use a simple long pooling request. Since you only want to get the SDP offer, the implementation is pretty simple.
No, you don't need to use the WebSocket API to send JSON data from client to client via a server, but unless you use Google's proprietary App Engine Channel APIs, then the WebSocket API is probably your best choice.
Also, please keep in mind that you're not only sending session descriptions, but also candidate info (multiple times) as well as other arbitrary data that you might need to start/close sessions, etc.
As far as I know, the WebSocket API is the fastest solution (faster than XHR) for signalling because all the overhead involved with multiple HTTP requests is non-existent after the initial handshake.
If you want to code things yourself, I'd start reading the latest WebSocket draft and learning how to code the WebSocket server-side script yourself or else you will pretty much have to rely on a WebSocket library like Socket.IO or a proprietary solution like Google's App Engine Channel APIs.
How about using the 303 HTTP status code?
The first client send the session description to resource X, the server acknowledges the receipt and responds with a 303 status code that points to a newly created resource Y that accumulates other clients session descriptions.
The first client polls resource X until it changes.
The second client send its session description to resource A, the server acknowledges the receipt and updates resource Y. The first client notices the update with the next poll and will now have the second client's session information.