I noticed my bank sends (after a merchant transaction has been initiated and paid) a POST response to my site (http) in plain text. This response contains every parameters of the transaction (card number, signature, etc).
Is this normal ?
I plan to reroute some of the responses to another server with a POST method (bank->server1->server2). Is it considered secured not to encrypt it ?
If the request to your server is not secure (using SSL, HTTPS) it means that anybody in between your server and the sender that is hijacking the connection could read the information. So, in this sense, the answer is no.
Note, however, that the connection between your server and the bank is a lot less prone to hijacking, which usually occurs between your client and the bank. Only people involved in the datacenter your server is in, are on your server, or are somehow on the same connection, are able to plan a (Man-In-The-Middle)-attack.
To elaborate a little bit more: is it normal? Yes, it happens a lot. Is it good? Probably not.
I would definitely secure your connection to your other server.
Related
I am working on a mobile app using Corona SDK. One of its core functionalities requires sending data between the app and my server. My question is, at what point do my attempts at making the data transfer secure become redundant?
The server side consists of a few PHP files and a single MySQL database. I have an SSL certificate and I validate the data at both ends. The app itself only makes network requests via HTTPS/SSL using HTTP POST and the data being transferred is a JSON string.
To this point, I believe that I have done everything as they should be done. However, as an extra precaution, I also encrypt and decrypt the JSON string at both ends using AES256-CBC.
Is this extra encryption at all necessary or is it redundant?
HTTPS protects the transport between the client (browser) and the server. It specifically does not protect data at rest at the server side (i.e. inside the database) not does it protect the transfer of the data between the PHP application to the database.
It is unclear if any protection outside the transport between client and server is needed. But it seems that your AES encryption will only protect the same path as HTTPS already does. In this case it will likely not add any protection. It might maybe add protection against legal (or malicious) SSL interception but if the encryption key is send over the same communication channel as the encrypted data then it will not actually add protection.
First of all, a better question would be is this possible? My gut instinct is that it isn't entirely, but there may be some clever ways. Even if they just act as a deterrent, make it slightly harder for some one to hack, or even make it easier for me to detect suspicious activity.
Basically, I'm building a web service using PHP for my C#.NET program to connect to. Among other things, one of the most important purpose the web service serves is verifying license data. The program sends the licence key entered by the user to be checked, and if it is valid the web service will return the Name of the person who purchased the licence key so that the program knows to activate itself.
I am fully aware that there is no perfect anti-piracy scheme and that is my software will be cracked if people want it bad enough. However, I do not believe that there isn't anything I can do to make it very hard for people to crack my software.
I do have an SSL certificate so the program will be communicating with the web service using HTTPS, however that's the only security I have at the moment. I have thought about
Using long and obscure names so that the functions are hard to guess
Using MD5 to disguise the functions
Adding a username and password
Checking the User-Agent
etc.
However, I have read that there are applications available to simply extract strings from programs, which would render those measures completely ineffective. Still, I don't know how technical users have to be to use those applications. Is it still worth adding some of these measures to stop casual piracy? Which measures are the better ones and what will be the most effective?
Thanks in advance
You can distribute your C# application with a certificate bundled and sign your requests with the certificate. The server can then verify if the request was signed by your application and reject any other request.
Edit: Whoops, I only now understood that you want to secure you application even when in the hands of a malicious user. This, I don't think is possible. A hacker can decompile, scan the memory, read and decode files, etc and your certificate will be available in there if you distribute it with the application. An alternative would be to distribute an external security token (hardware device or flash storage) which will need to be plugged-in to the client computer. The token holds the certificate, keys or cyphers used to sign/encrypt your requests and it therefore doesn't stay with the application.
Your server-side SSL certificate will only guarantee that the communication channel is secure and the server is not lying about his identity. It doesn't guarantee anything about the client connecting. To also be sure that the client is identified, you need to use a form of client certificate that your server recognises.
I want to send very sensitive data to a webserver by calling a specific php file with data over GET or POST (not sure yet). The data contains 3 values, so I thought of building an own algorithm, but this could be reverseengineered easily and I guess there are far better solutions than those I have.
The difficulty is basically this: When a user buys a inapp purchase for a Windows App he gets access to this server. MS does not offer any OAUTH check like Google does so developers have to implement their own check. Also we don't have any user accounts.
Do you have any ideas on how to restrict users that haven't bought the purchase from accessing this server php file (which is secure)?
There are lots of 'handshaking' methods you could use. One method that has worked for me:
Open the channel to your server
Server sends a string of random characters to the client
Client hashes the string with a known salt and sends this string back to the server
Server compares the returned string with it's own encrypted version of the original string
If they match then the client session is allowed
This prevents someone from doing a replay attack on your server.
If you want to stick with a typical 'web transaction' then use HTTPS (port 443) to handle your encryption. Another alternative would be to use an encrypted socket to a different port.
I have a HTTP REST API in PHP used by an iPhone application.
Some webservices from this API are secured with a user authentication in the HTTP request credentials but I want to avoid "man in the middle" attacks by providing fully encrypted requests data.
I'm not really skilled in security issues and I couldn't find any clear answer to my question anywhere :
Is HTTPS relevant for STATELESS REST API ?
From what I understood, HTTPS does 2 things :
encrypt your session
prove to the client that the server he is talking to is secured
So at first sight it does not respond to my need which is to encrypt the data between my server and the application because the API does not use sessions. But I still have doubts.
Can someone make it clear to me ?
My other solution would by to encrypt requests data with public/private keys system. Would it be more suitable ?
Thank you !
Yes, it is. HTTPS has nothing to do with the application, it's a tunneling protocol. Even though TLS is itself a stateful protocol, the HTTP part going over it is not.
Just like if you were using a VPN, you can still have a REST based application. The TLS just sets up and tears down the tunnel automatically for each connection.
That said, there's value in leveraging the pipelining aspects of HTTP and HTTPS to improve throughput over TLS connections, but that's a performance tuning aspect unrelated to the application itself.
HTTPS is very relevant, and yes, that's because of the two points you mentioned. Did you know that OAuth 2 actually enforces HTTPS?
Doing all the encryption yourself could be an option as well, but you lose the part where the API is easy to use.
Most man-in-the-middle attacks on "simple" HTTP requests involve stealing credentials and faking requests, but they can also read the data sent and received. If your issue is with the data being unreadable, use HTTPS. If fake requests are the only problem, an authentication protocol such as OAuth 1 (not 2) would suffice.
If you do not want to implement SSL you may want to check out http://www.jcryption.org/ I don't know if it will work in a stateless environment, but may be worth a try. It is basically a jquery plugin that handles creating key pair associations for data being transmitted. May only be for form submission though. We used to use it to encrypt login credentials at my old company.
Definitely use, HTTPS if the data is sensitive - it encrypts at the transport layer which is what you are looking for. As already pointed out oAuth 2.0 mandates it essentially. You can potentially avoid man in the middle by using hashing/signing as in oAuth 1.0 and avoid having to use SSL but the body still goes in the clear then (you've avoided sending the API credentials in the clear but not the body).
I am implementing kerberos in php. Here, a trusted authenticating server issues ticket for the purpose of authenticating client to other server. Thus there involves transferring of tickets and ids, etc among the three entities( auth server, client and other server). So now the question is what can be use to transfer data?
For example, the client logs in on other sever. The auth server creates an encrypted ticket for client.Now this must be transferred to the client. similarly client needs to send this ticket to other server, so that other server can verify it.
I have some options like cURL or javascript XHR.
I'm not sure if they can be used in this situation. I seek someones guidance.
Thank you.
I would go with cURL.
If you use Javascript you are exposing URLs where you are going to process data, and this could make a possible security breach.
Ofcourse, you must never trust user-input, but to me it's simple:
Only use server-side