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 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!
I'm PHP developer and I know very little when it comes to https/ssl, but I would like to offer my client safest possible way of uploading file to webpage (i.e. webftp as part of client service on page).
Which way should I look?
Thank you in advance, I will clarify my question if needed.
I'll probably disappoint you, but without HTTPS or some other form of encryption, all the data passing over the wire is plaintext - this also holds for FTP. (In other words, it's practically impossible to verify that the data which the server has received actually came from the client, and hasn't been modified.)
Valid (and widely accepted) HTTPS certificates are cheap and relatively simple to use, plus it's probably the optimal solution currently available in terms of safety*simplicity (switch URLs from HTTP to HTTPS, no other configuration required from end user). With a valid SSL certificate, the client could be reasonably sure that they're communicating with your site and that the data is encrypted while in transit.
In other words, there are safer (but more complicated) alternatives (such as encrypted VPN), and there are simpler (but less safe) alternatives (such as plain HTTP). HTTPS done right is about the right combination of safety and simplicity for a general-purpose website. (OTOH, if you're trying to protect top-secret NSA files, HTTPS is definitely not enough)
I'm sorry, the browsers themselves offer no alternative to either sending the file in plain text or sending it encrypted through HTTPS.
The only alternative would be to use some sort of client side plugin (e.g. a Java Applet) that would encrypt the file prior to sending it (as a bonus, you could compress the file before it was encrypted and sent). However, this solution hinders compatibility by requiring a plugin to be installed, is much more complex and ultimately rendered unnecessary by the existence of HTTP over SSL/TLS (HTTPS).
I roamed the site for this question using the search engine, and I don't think it's out there. If it is, apologies in advance and feel free to point me to it.
Here is my scenario:
I am setting up a web application, Moodle if anyone is familiar with it, with Apache, MySQL, and php on Windows. Moodle supports enabling SSL for login, but then reverts to regular http after login is established. This is running on an internal network with no connection to the outside world, so no Internet access through this network. All users who use the network have logins, however there are some generic guest type logins with certain restricted privilages. Currently the MySQL database is not encrypted.
My question is this:
If my users do an SSL login, and the system then reverts back to http for the remainder of their session, how vulnerable is the data that is transferred back and forth between the browser interface and the database?
I would perhaps prefer to have all the data encrypted, but I am not sure how bad the performance hit would be to do that, so any suggestions concerning that would be appreciated too. Although I will be extending the functionality in Moodle, I don't necessarily want to have to change it to encrypt everything if already does.
I am new to the world of IT security, and my DBA skills are rusty, so if you give me an answer, type slowly so I can understand! ;)
Thanks in advance!
Carvell
A few things.
The fact that the data in the DB server is not encrypted in no way is a factor in the communication between the User and the Web Server. It is a concern obviously for communications between the web server and the database server.
Your risk point between user and web server is in that packets could be sniffed if a person was able to interject in the middle of the communication chain. However, this risk is mitigated by the fact that your on an internal network.
Therefore, unless you are VERY concerned about the other people in your organization, you are more than likely ok. However, if it is really sensitive data, you might do ALL communications via SSL to ensure that it is transmitted securely. IF you are this concerned, then I would also look at the security of the DB and the communications from DB to webserver.
My concern would be how your authenticated sessions are propagated.
Generally a session works by setting a cookie or appending a session id to any URLs presented by the web site. Once a log-in has been established, often the credentials aren't needed any more, as a session is then linked to the user and deemed to be authenticated, and the existence of the session itself is proof of a successful authentication.
However, as previous posters have mentioned, local network traffic can be available for sniffing. If someone sniffed a session id, they could recreate the cookie or urls using the session id, and simply access the site as that session user, even changing the user's password if that option was available.
I would say that your decision here rests on the security of your sessions. If you have some mitigating factors in place to make sessions difficult to replicate even if a session id is compromised (ie. comparison to ip addresses, etc), or your user accounts are relatively secure from a compromised session (eg. require current password to change account settings), then perhaps SSL after login isn't required. However, if you have doubts and can afford the performance hit, then having SSL throughout the site will guarantee that your sessions can't be compromised (as far as you can guarantee SSL, anyway).
With no internet access to this network, the only thing that could potentially happen is someone else (who is already on the internal network) snooping on another user's HTTP traffic. If someone were to actually do that, and you aren't using SSL, they could read all the data that your website is sending/receiving from that user. But is that actually a concern?
Since you are on an internal network turning on SSL for the whole site should not be that bad performance wise, although it is probably unneccesary.
At the very least, you should encrypt the data in your database.
All sensitive data should be encrypted when transferred over an insecure wire. If you just transfer login details over SSL, all your data is still vulnerable to eavesdropping.
Since the data's not encrypted, anybody with sufficient network access (i.e. physical access) can read the data passing back and forth from server to browser and back. As long as everyone who has physical access to the network also has authorization to read the data, you're probably alright. If any of the information is sensitive, and should be restricted to being viewed by a subset of people who have physical access to the network, then you need to encrypt it.
Anyone on your network would be able to see everyone else's traffic with a network packet sniffer like WireShark. The connection between your web server and MySQL is also in cleartext. MySQL may not actually send passwords in cleartext; it may be a hash, for instance.
If you are really trying to be paranoid, you may not need to run your app over HTTPS. There are other lower-level possibilities like IPSec. Since this is an internal network, you can probably get away with implementing this on all workstations.
Not much to add to the above correct responses. But, one think you can do is use a Threat Modeling tool for your application. That will inform you on the types of threats you are exposing your data to by not using transport level encryption (TLS/SSL). Once you understand the threats, you can decide on an appropriate risk mitigation plan.