I have created web service for android in PHP that uses GET method. Now I want to convert it to POST, to make it more secure. How to convert the application from GET to POST? Is there any other way to make it more secure?
The answer depends on who you want to secure it from. Assuming that you want to protect from network sniffers, SSL is your best option.
POST is the weakest form of "security" you could suggest. All it does it prevent the parameters being visible in a browser's cache history (which doesn't affect you at all in this case) and make it a fraction harder to sniff the parameters over the network (which does affect you). So there's minor benefit (yes, it's worth it), but it's not secure at all.
The simplest solution is to POST using SSL. In other words, as opposed to posting to "http://example.com" you should post to "https://example.com" with a valid certificate on the server. That will encrypt the traffic between device and server. Google for suggestions, or start Secure HTTP Post in Android
Failing that, you could encrypt the data yourself and then send the encrypted query openly as only your server can decrypt it. A little bit of Googling will give you code on how to encrypt in one and decrypt in the other securely - but as a small warning, getting it to work can be frustrating as it won't work until it suddenly does... there's not much debugging you can do when it doesn't work!
Related
I have a PHP page on my SSL server which acts as a REST API effectively. What I need to do is take the unencrypted password from a different domain and POST to my page. After this, the server returns the encrypted data in JSON. I do this with my current website as a POST from the same domain is completely secure but I am not sure about from a different domain? Is there any way a hacker can intercept the POST data before it is encrypted?
Thanks
Kabeer
I didn't comprehend what you're describing in your question, but as for your title:
Is posting unencrypted passwords to an HTTPS server unsafe?
No, it is completely safe. Millions of websites do this every day via their login forms.
If you are receiving the POST data via HTTPS, then it is encrypted in transit and not easily intercepted. It is encrypted using a shared symmetric key between the client and the server, so that only they can decrypt each other's messages.
See How exactly HTTPS (ssl) works
I wouldn't say it is safe, but I would agree that it is fairly common to pass unencrypted user/pass and only depend on TLS/SSL...
TLS/SSL has been compromised a few times over the last couple of years, so depending entirely on it can involve risk.
I want to set up some basic web server protection to protect against replay attacks and data manipulation hacks.
At the moment, I make a REST request from the client (android) side such as:
http://www.example.com/add_book.php?user_name=eddy&nonce=534365756756&book_title=My%20First%20Book
Here, I am using a nonce that will be stored against the user's id and checked for duplicate requests. However, in this unencrypted system someone can simply insert their own (random) nonce. What I want do is convert the above request to something along the lines of:
http://www.example.com/add_book.php?fsjdfhdhsjfhdsjf538537854rj34i5348ur4rf4r3g4yrg4y32210dfsdjfsdhfjshru99jifjknjsdfnfjsfhuruwe
that can be unencrypted server side to the equivalent unencrypted URL so the parameters can be accessed with $_GET['book_title'] (like in the usual manner).
In the ideal world, the request itself could be encrypted with the user's hashed password as an easy way to certify the user is who they say they are.
I'm not really prepared to pay for an HTTPS certificate at this stage so that's not really an option.
Does anyone know how I can do this? My requests are plain text atm so are incredibly vulnerable.
Thanks.
Android encrypting URL parameters and values and decrypting server side
Don't encrypt URL parameters!
I want to set up some basic web server protection to protect against replay attacks and data manipulation hacks.
If you're trying to stop someone on the network from intercepting plaintext HTTP requests and manipulating them maliciously, HTTPS is the only solution you have.
If you're trying to stop a local user from doing the same, rethink the security model of your application.
I'm not really prepared to pay for an HTTPS certificate at this stage so that's not really an option.
You don't have to pay anything for HTTPS. It's free!
If you're using a hosting provider that makes it difficult to get HTTPS for free, set up a cheap VPS (LowEndBox, DigitalOcean droplets, etc.) and stop giving them your business. They'll adapt or die.
I'm developing a web site which calls .PHP scripts to inject data into a MySQL database.
Because there is no security on these .PHP scripts, anyone in the world could run them over the web if they knew the proper parameter names and inject data into our database.
I know very little about security so I'm looking for a solution to secure these "web services".
I've read that using SSL may be the way to go but I'm not sure.
If anyone could make a recommendation and point me to a tutorial or website on how to implement this I would be greatly appreciative.
We are using Apache web server by the way if that matters.
SSL will not solve the problem by itself. If someone can hit http://yoursite.com/service.php, they can also hit https://yoursite.com/service.php. SSL simple ensures that the actual data going over the wire is encrypted. But an encrypted injection request will have the same effect as a standard unencrypted one - you'll still have data injected into the database.
What you need is a password system of some sort. A bare bones minimal system would require a secret word to be sent along with each request, and any request without that word gets rejected/ignored. however, then you have to keep this secret word secret, and nothing on the web stays secret for very long.
Next up is assigning a specific key to each authorized user of your service. Nothing would prevent the users from sharing their key with others, but then you've got a per-user key that you can track down and beat up the person who DID share their key.
Past that, you can use HTTP level authentication, coupled with per-user access keys, which should prevent casual poking at the API. Without the http-level password, the API script is not even invoked, and even when it is, the proper API key must be present as well.
I'm using loadVars to load a PHP URL with lots of sensitive information required for the Flash application. Only problem is that URL can be accessed via a web browser which raises security issues if someone gets a hold of this URL. Is it possible to have the PHP page only accessible via my Flash application?
Appreciate the help!
Thanks
No, there is no way to limit a page to a specific app, browser or user agent, since all of those things can be mimicked. If you are passing around sensitive information then you need to do authentication and use encrypted data transfer (HTTPS).
Regardless of how you attempt to make it only accessible from your Flash application, a determined user will certainly be able to view the page also. It can be as simple as proxying the requests through an HTTP proxy like Charles, Firebug or Wireshark.
There are things that can be done to make it more difficult to figure out what the data is from viewing the page directly. For instance, you can encrypt the data or output it as binary. But since SWF is an open sourced format, users can use decompilers or just inspect the ABC (Actionscript Byte Code) to see what is really going on.
The short answer is NO, you cannot protect the information available to the client side (Flash) from being accessible from other clients.
As long as you have a page on HTTP, a determined user can always find a way around any user-agent restrictions imposed by you.
One way to protect the data (other than using HTTPS) is to encrypt it at the server, send it over HTTP and then decrypt it in Flash using as3Crypto or some other cryptography library.
Hope this helps,
I want to secure the login page on my blog when my browser sends my password to the server (http) as I don't want anyone to steal it.
How would you do it?
As far as I am aware the only real way to do it from a production perspective would be to use javascript to encrypt the data sent in the form and then decrypt it at the other end.
There appear to be a couple of JS classes for this purpose, e.g. http://www.jcryption.org/
jCryption uses the public-key algorithm of RSA for the encryption.
Then a third party packet sniffer would have to know the decryption key to be able to do anything with the data.
I would recommend using SSL for all login's though! Personally I tunnel all my traffic over a VPN so I know it is slighty safer when in public places.
You could only allow the use of the login page over an SSH tunnel ;) However I think SSL is then much less burdensome.
The javascript suggestions I don't know what I should think about those. The key must be shared between client and server so this needs a secure key-exchange as well. That's not trivial at all and I suspect that only very few really good libraries for that are around. The basic suggestion to "encrypt" something with javascript will most certainly just fail.
Use JS to perform RSA. Encrypted it before posting it to the server. Then decrypt it when reach the server
If you ask me, I won't use non-SSL encrypted logins. As soon as sessions are involved I switch to SSL as session stealing without SSL is just too easy. Also SSL allows me to protect my pages with Basic-Auth, so I do not even need a session.
So perhaps best is to consider switching your Blog to SSL entirely. Note that for using SSL on your server you just need an SSL certificate. There is a company out there which offers a free ssl certificate for 0$ per year. Also note that Google and all major search engines can handle https pages without trouble.
I skip the 1000 lines of answer how to implement your own secure password scheme using JavaScript and AJAX over insecure lines, because this is difficult to implement.
Two options how to securely login without JavaScript and without SSL come into my mind:
There is a cheap one time password USB device out there. You just plug it into the USB port, press the button, it creates an OTP and here you go. As it is an OTP it only is valid a single time, so no replay and no problem when it is sniffed.
The other thing is OpenID which is used here on stackoverflow. OpenID does not need SSL between server and client. Note that this USB token above already is OpenID enabled as well.
Both ways offer trainloads of free libraries to implement it using PHP or other languages. It certainly is easier to implement than to create a properly designed and secure password scheme yourself over insecure lines.
One big caveat, however:
If you use sessions over insecure lines, and logins ususally use sessions, be sure to protect the session at least by the IP seen. This must be implemented on the server side. This way, if somebody steals the session Cookie the session cannot be (ab)used, provided that the thief does not share the same wLAN (or computer) as you.