Principle of HTTPS operation
HTTP protocol is built on top of TCP. TCP guarantees that the data will be delivered, or it is impossible to deliver (target not reachable, etc.). You open a TCP connection and send HTTP messages through it.
But TCP does not guarantee any level of security. Therefore an intermediate layer named SSL is put between TCP and HTTP and you get the so called HTTPS. This way of working is called tunneling – you dump data into one end of (SSL) tunnel and collect it at the other one. SSL gets HTTP messages, encrypts them, sends them over TCP and decrypts them again at the other end. Encryption protects you from eavesdropping and transparent MITM attack (altering the messages).
But SSL does not only provide encryption, it also provides authentication. Server must have a certificate signed by a well known certification authority (CA) that proves its identity. Without authentication, encryption is useless as MITM attack is still possible. The attacker could trick you into thinking that he is the server you want to connect to. Private chat with the devil is not what you want, you want to verify that the server you are connecting to really is the one you want to connect to. Authentication protects you from MITM.
So where are the weak points?
- Endpoints of secure connection. The transfer could be secure, but what about the server itself? Or the client? They may not.
- Not using HTTPS. Users can be tricked into not using the scheme in various ways.
- Untrustworthy CAs. They break the authentication part, allowing for MITM attack.
- Weak encryption mechanism. Crypto technologies age in two ways: Serious flaws might be found in their design, leading to attacks much more efficient than brute force, or their parameters and processing power increase due to Moore's law might allow for a feasible brute-force attack.
- Implementation of the scheme. Well, if you specify A and implement B, properties of A may not hold for B.
You seem to say that you secured the transfer (using SSL). This is not enough, the security of your server can be compromised – you should not store passwords there in plain text, use their hashed form, with salt added, …
SSL encrypts data both when sending and receiving. MITM attacks are possible virtually only when the attacker has certificate signed by an authority the client trusts. Unless the client is tricked into not using HTTPS, nobody can read nor modify the messages being sent.
GET and POST are just two methods of making HTTP request. There are several other, too. Method is just a property of HTTP request. All messages are secured, both requests and responses, regardless of HTTP method being used.