In asymmetric encryption, public keys can be used to encrypt messages sent to a device with the matching private key. I understand that this prevents sniffers from knowing the content of a message, but consider this:
What keeps a hacker from using the public key to encrypt messages and pretend to be someone he\she is not? Say I am shopping on Amazon, and a hacker managed to capture amazon's public key when Amazon exchanged it with me. Couldn't this hacker pretend to be me by simply modifying the headers of his packets to look like they came from my computer? I know this doesn't happen, so what am I missing?
a hacker managed to capture amazon's public key
Amazon's public key is public. Everyone knows it. The one that was issued May 3, 2018 begins "A9 F4 4A 9B 29 84 20 A7 53 FF BA 01 B5 1E 0C 2A A7 53". The whole point of public/private key cryptography is that the public key is not a secret. So capturing the public key is not important.
Your question isn't about masquerading as Amazon to you (i.e. having to do with Amazon's keys). It's about masquerading as you to Amazon. That's a completely different situation. You don't identify yourself to Amazon with a certificate (called a "client certificate"), so certificates and public/private key cryptography have nothing to do with this. Yes; anyone could send a message to Amazon encrypted with their public key, but that's not how you prove you are who you say you are.
Instead, you identify yourself to Amazon with credentials, typically a user name and a password. When you do that, Amazon hands you back a session token, which is just a big random number that is mapped to you in a database table (or sometimes the session token is encrypted information about the session so that the database isn't needed). Once you're authenticated, you keep passing your session token back to Amazon to say "you already know and trust who I am."
So what if someone captures the session token? That would be a big deal. That would absolutely allow exactly what you're describing. The session token has to be protected for as long as it's valid. We protect it when we pass it to Amazon using TLS which "prevents sniffers from knowing the content of a message" so attackers hopefully can't discover the session id.
There are many attacks to steal the session id, broadly called "session hijacking." One of the more famous was Firesheep, which relied on unsecured (HTTP) sessions. However, there are more advanced attacks against HTTPS, such as CRIME and BREACH. Improvements in TLS have mitigated against various known attacks, but it is always possible that new ones will emerge.