my app api is captured with http carnary app which the hacker could access the api.
Is http request authorization could prevent it?
Basic xxxxxxx
I dont know where to ask. Been strugling for days without result.
Disable HTTP without TLS on your server, use certificate pinning on the client. The attacker will only be able to see requests (by reverse engineering or modifying the application). There is no way to be 100% secure in this case. If the user has network access he will be able to see the data. HTTPS and certificate pinning will be reasonable big obstacle for most attackers.
Related
I have web services made in PHP which gives response in JSON. I have used these services in one of my iOS app.
But when I use web debugging tool like fiddler it shows all the data passing to my web services. Either I used GET or POST method.
How to secure the communication between server and the client application? Also which kind of encryption should be used to secure the data and where it should be used like either on server side or client side?
I have seen some methods like ssl/https connectivity to secure data. But I don't know how to implement that in iOS?
To Secure web service data you many people follow below authentication procedures
Basic Authentication, Authentication with NSURLConnection sendAsynchronousRequest with completion handler
OAuth 2.0,
https://github.com/nxtbgthng/OAuth2Client
SSL and TLS Authentication procedures
http://www.techrepublic.com/blog/software-engineer/use-https-certificate-handling-to-protect-your-ios-app/
Before you implement in iOS ,your backend developer (in your case PHP Developer) need to implement in the backend side and provide necessary information to you
If you use https all data is encrypted except the URL address. Some diagnostic programs can show the unencrypted communication by setting up a proxy on the device, this and MITM attacks can be averted by pinning the certificate if you are connecting to a known https server.
I am currently learning about OAuth2, and I am slightly confused about one part of it. Does the OAuth2 server compare the domain in the JWT with the domain in the request header?
What prevents someone from ripping a bearer token out of a JS app and then using it to make fraudulent API requests? Even if HTTPS is used, the token sent back from OAuth2 still has to be stored before it can be used in subsequent requests, thus making it vulnerable. What am I missing?
Edit: what if I create an oauth2 token from a non-browser client and there is no domain name to match against?
Nothing prevents it from being used. That's why you store it safely or you don't store it at all.
I intend to have a PHP web service accepting JSON-RPC over TLS (HTTPS). Every client will have an API key that I will use for identification purposes. Is that enough security, is there a JSON-RPC security specific standard?
That's a fine way of doing things. Here's an overview of the requirements and components play in your security scheme:
Checklist
Here's the checklist of what security is needed, and how you would address it:
A third party can't eavesdrop on your communications. HTTPS provides this.
A third party can't tamper with your communications. HTTPS provides this too.
The client can authenticate the server. HTTPS provides this (*).
The server can authenticate the client.
Client authentication
There are lots of way to authenticate the client. Here are a few exaples:
Use the API key to calculate an HMAC of the request and include the HMAC as a header in the request. (**) The most secure, but more complicated to set-up. The key advantage is that should your server be compromised, API keys won't be exposed.
Include the API key itself in the request. Easier to set-up, may be sufficient security depending on your requirements.
...
(*): So long as the client library does. HTTPS requires that you use a certificate that validates your site corresponds to the domain name. Unfortunately, many HTTPS libraries do not validate this by default.
(**): You should also use a nonce to prevent against replay attacks.
You could be signing a request using a secret salt (+hashing algo of choise, MD5 will do fine) because this way an eavesdropper cannot obtain the "API key" and forge his own requests. Use a very long salt.
The salt also acts to protect against intentional altering of a message by a successfull eavesdropper.
How can there be a man in a middle? TLS(SSL) is not much security against man in the middle attacks, unless you issue whitelisted certificates per client. For example, the server in the middle (attacker) obtains valid certificates, or the client application is not checking for various certificate validity settings (expiration dates, etc.). If not under your control, it is likely that clients of your RPC server will connect without doing any sort of security checks. This is a widespread problem. Eavesdropping usually implies access to your (or your client's) network so this could mean poisoned DNS traffic redirects to the rogue server.
Wether your or your client's network connection is secure enough to exclude the possibility of DNS poisoning, or your client is checking the certificates for validity, or you force the client to use whitelisted SSL certificates, are things only you can influence or decide upon.
You might also want to prevent replay attacks by assigning a unique number for each request (possibly overkill if these API calls are just for reading) for denying duplicate requests.
The API keys you mentioned, are generally used when browser side JavaScript clients are involved to track usage. API keys are reissued, when stolen, to identify and disable unauthorized apps (and maybe automatically make a list of the fraudulent domain names for further [lawsuit] action).
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).
There's a payment server. I can successfully send data via cURL and set appropriate key and certificate and payment server successfully answers. But now I need to make a redirect to that server so that client can enter credit card data. How can I make that redirect?
Is there a possibility to add key/certificate as a part of headers in function header("Location: https://...."); ?
Even if you could send the certificate along with the redirect, the browser still has to verify it. But you can't. It's impossible. You have to send a regular redirect. Because it's a https address, the browser will first request the certificate from the target host and verify it (including necessary user intervention). The outcome is the same.
There is no way to circumvent the popup dialog requesting the user to accept/trust or deny the certificate. HTTPS is designed to ensure "reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted." (Quote from Wikipedia)
Unless the provider has a very weird setup, I don't think you can. There are two clients cpnnecting to the server - first your PHP code which is using the client certificate, then you expect a browser somewhere to be able to bind to the same session without the client certificate? The only way this would make any sense is if the payment provider sends back a surrogate authentication token - and if they did that they'd provide detailled documentation. Obviously that is not the case.
While you could proxy the data on your server, I'd strongly recommend you switch to a different payment provider which handles the entire payment process for you.