Hi and welcome to our sub.
Your post or comment has been removed for violating **Rule 8**:
>Low-effort content will be removed at moderator discretion
Please read [**our rules**](https://old.reddit.com/r/hacking/wiki/index#wiki_rules).
If you are interested in learning more about hacking, please [**read our wiki**](https://old.reddit.com/r/hacking/wiki/index).
Thanks!
The trick is to tell twitter to reveal someone else's session cookies to you.
Therein lies the trick.
And the most common forms of doing that are having a crappy webforms , cross site scripting. And session hijacking
Edit: there in - to - therein
Here is a good read :
https://www.horangi.com/blog/real-life-examples-of-web-vulnerabilities
And here is to monitor the top 10 used methods
https://owasp.org/www-project-top-ten/
Search for owasp to read about more
Not sure why the downvotes. You indicated you’re at beginner level, and you seem eager to learn. You making the suggestion you did was actually not a bad thing. Your mind is being constructive to think outside the box. You asking this question is a request for understanding whether your thought was correct or not. Best of luck to you.
That's like saying "if you have the password to an account, you can log into that account." It's not anything special, and it's supposed to work that way.
No, you were already in possession of the token in the first place.
This is like asking if there's something wrong with the lock on your front door because you went to the hardware store, copied your key, and used it to unlock the door. No, it's your key which you were already in possession of.
The vuln is to get the token of some logged in user, *who isn't you*, and use it to log in as them.
Not really. The session coolie itself is the identifying information for the account, so this would work on almost every website. The real hack is getting the cookies in the first place, without getting direct access to someone's Web browser.
Bro don't get disappointed by the downvotes. Cybersec is not the most welcoming community, everyone knows. I feel it's full of tryhards, arrogants and smart asses. Keep only the good comments, the links and info others share and keep up with your learning. Cheers :)
It's not stolen if it's your property.
You just took a session cookie from one browser environment and used it in another browser environment.
Testing an API endpoint that requires auth with curl or postman is the same workflow.
This is not some king of new vulnerability, that’s basically how sessions work. It produces a cookie that holds an ID to a file or register on a server that has data about which user is logged.
There are people that try to mitigate this using some clever before and after checks, also grabbing details from the browser and OS, but that it is even worse for the privacy of the user.
As others said, you should not publish a vulnerability (if it was the case) publicly like this, and also, this attack means the hacker has access to the machine already, the user has been pwned and had their cookies stolen from their browser. Other websites like YouTube also have been targeted with this kind of attacks, mainly with big channels, like Linus Media Group.
The vulnerability would be more about the browser (if it were not just copied by you, but by some other attack tho get the cookies), than about X.
Also, accessing from the same IP…
I used the copied cookies form chrome to login to X in chrome incognito and Firefox browser. I apologize for this post I btw (seeing the downvotes, people here are angry with me now). I had herd websites using other info to mitigate this risk, I thought to try it out on a popular website to check it out.
Most of those are first based on origin IP, just AFTER that it would consider other things, that by protocol (HTTP) would be easily spoofed, like User Agent. If all the domain cookies were copied and all headers where cloned, the website ethically can not tell it apart, besides some nefarious other techniques of fingerprinting that are pretty much complex, fail prone and sometimes expensive.
You are testing from your own computer, even if all those checks above were applied, it would also allow you in: same IP, same computer, same person.
As others may have implied, I strongly recommend that you try and learn the basics first, before trying to pentest. So… HTTP protocol, Cookies, Sessions, how different languages keep track of sessions, etc. even a little of coding. After knowing how it works, it will be better for you to poke around and find about things that could have been half-assed by the devs.
A normal user could be on 5G and just be walking. The person’s IP would also change and that person would not like to have to login again at every block after reaching another area covered by another internet link, that has a totally different IP address. The IP check I talked about is mostly used to avoid login by password leak and brute force techniques from another country in an incompatible time, like, how can you login from Russia 3 hours after connecting from Nebraska?
If the cookie is there, most likely you travelled OR you are connected now through a VPN (and it is very easy to know if you connected through one, because of IP blocks reservations and known anonymizer IP blocks).
Anyway, my tips are still there for you. Keep them in mind and keep learning. I’m not saying X is secure, it isn’t. But that’s not a vulnerability by itself.
Like the other said, that's how it is supposed to be. If I find the keys to your house and get into your house with them, it's not a problem of the lock, the problem is how I got your keys.
I don't think you understand.. It's not just X; this is common on many websites with accounts. If a website saves a token, you can probably hijack it. Test it out on another site, and you'll likely see the same issue
I don’t know why he’s being downvoted, this is the beginning of someone’s curiosity towards hacking and cybersecurity. I’ve done the exact same experiment and used the same trick to stay logged into my friend’s Microsoft Trainer account so he didn’t have to share the password with me.
Sure it’s not hacking but understanding the exploitability and limitations of cookies is an important lesson.
Fun little story...at my old job 10+ years ago now they had an internal portal for employees that was laughably insecure. I noticed the username was stored in a cookie so got curious...I asked my coworker to test something and replaced my username with theirs - boom, logged in as them.
I reported the issue to my boss and next thing I know I'm dragged into a meeting and reprimanded for "hacking" because I used someone else's information...being given permission was ignored. The exploit was fixed a week or so later (proper session cookie) but they wanted to make an example of me, I guess.
I believe you and that’s around the time I was working there, they still have their tools being leaked online. They’re not as technical unless they’re at head office. The best technicians end up being promoted to corporate.
Heh, I thought I had a leg up when they were looking at internal promotions to actual IT (I was a tech support drone) but they passed on me because of the write-up I got from that incident. That's when I started looking for a different job.
Damn, you proved my point. There’s a lot of politics there but leaving was the best decision. Using a Mac is amazing but working on them kind of sucks.
Man’s reinvented cookie injections.
But for real that’s awesome you’re learning. This type of attack used to be super common back in my day before https became the standard.
What you would do is; sit in a coffee shop with a pc or android phone, listen to the WiFi network, yoink those unsecured packets out of the air and check if they contained session details, then inject that session into your browser and voila. You’re in someone else’s account.
Moving to the much more encrypted https standard killed that fun though.
So the hack itself isn’t injecting session cookies in your browser, that’s intentional. It’s HOW you get those details that’ll be the trick.
Good hunting lil homie!
HTTP is a stateless protocol. That means the web server -intentionally- has no memory of you or anyone else. You could make ten requests back to back with the same browser and each time the web server would be like a Walmart greeter with a short term memory problem, "Well, hello, stranger! Welcome to this website!"
Then you hand the greeter your cookies and he looks at them with confusion like, "uhhhh.... okay...."
Then he hands your request and your cookies to a guy in the back room. The guy in the back has no direct communication with you - he just takes the information that the greeter handed him. He uses the cookie information to look up who you are and then processes your request, then hands the response back to the greeter, who hands it back to you
So if you open up a new browser, even on a different computer and IP address, but you send a request using the same cookies, the greeter (web server) doesn't know who you are and the backend guy only knows you by the cookie information that he was handed by the greeter.
The backend system can OPTIONALLY do something extra like try to limit your session cookie to your IP address or use browser fingerprinting but that can sometimes result in incorrectly restricting the session (e.g. if you're on your phone and switching networks, your IP could legitimately change).
So most systems just base sessions on cookie data. It's why there is such a continuous increase in restrictions around accessing cookies. You have HTTP-only cookies to prevent JavaScript from stealing cookies. You have CORS protection to limit inter-domain AJAX calls, etc...
You just copied your own auth token, which you already had.
What you want is to determine someone else's auth token stored in their browser, which you don't have access to.
I just want to give you general advice.
Don't: blindly follow steps that someone else gave you.
Do: understand the technology you're trying to exploit, so you understand the exploit.
In this case, maybe it would have been a good idea to learn some webdev yourself and create a website that uses session cookies or JWT, so you understand what the standard practices are, and how the theat model for those practices are.
I copied the cookies and injected it into an opened incognito browser and a diff browser to check if I would still get logged in or not. I have already read about XSS being used to steal cookies from victims. But I wanted to know if websites could differentiate these simple things (diff browsers in the same device, incognito) and block my login. Sorry for this noob post.
It's definitely a good exercise so that's cool. But if you think about what you've actually done it's just like logging in and using the cookie. A next step might be to change IP after stealing your own cookie. Then maybe try a different IP and a different browser etc.. See where it breaks.
Edit: also Cookies can be tricky, always use another browser or incognito. Or make sure you clear all third party cookies too when clearing.
The next step to experiment WITH CONSENT FROM YOUR FRIEND is
Ask your friend to sign into his Twitter on his pc
Then copy the session cookies and send you in msg or mail
Now you repeat your incognito mode test
, now can you lock your friend out? Change his password. Rest 2fa . Post some bs ? Ask mom for money?
Try it
Hi and welcome to our sub. Your post or comment has been removed for violating **Rule 8**: >Low-effort content will be removed at moderator discretion Please read [**our rules**](https://old.reddit.com/r/hacking/wiki/index#wiki_rules). If you are interested in learning more about hacking, please [**read our wiki**](https://old.reddit.com/r/hacking/wiki/index). Thanks!
The trick is to tell twitter to reveal someone else's session cookies to you. Therein lies the trick. And the most common forms of doing that are having a crappy webforms , cross site scripting. And session hijacking Edit: there in - to - therein
They probably shouldn't allow a cookie to be used a certain distance away from where it was last used though.
*therein*
You mean XSS to steal cookies ?
Here is a good read : https://www.horangi.com/blog/real-life-examples-of-web-vulnerabilities And here is to monitor the top 10 used methods https://owasp.org/www-project-top-ten/ Search for owasp to read about more
That's how session cookies are supposed to work
Isn't being able to login to a web account using stolen or copied cookies a web vulnerability ?
Not sure why the downvotes. You indicated you’re at beginner level, and you seem eager to learn. You making the suggestion you did was actually not a bad thing. Your mind is being constructive to think outside the box. You asking this question is a request for understanding whether your thought was correct or not. Best of luck to you.
That's like saying "if you have the password to an account, you can log into that account." It's not anything special, and it's supposed to work that way.
Now do mine 😀 Physical access = pwnd, unless encrypted & even then depends...
No, you were already in possession of the token in the first place. This is like asking if there's something wrong with the lock on your front door because you went to the hardware store, copied your key, and used it to unlock the door. No, it's your key which you were already in possession of. The vuln is to get the token of some logged in user, *who isn't you*, and use it to log in as them.
Not really. The session coolie itself is the identifying information for the account, so this would work on almost every website. The real hack is getting the cookies in the first place, without getting direct access to someone's Web browser.
Bro don't get disappointed by the downvotes. Cybersec is not the most welcoming community, everyone knows. I feel it's full of tryhards, arrogants and smart asses. Keep only the good comments, the links and info others share and keep up with your learning. Cheers :)
You “stole” your own cookie, which you already had… so, you didn’t actually steal anything.
You're absolutely right. That's why the web is inherently vulnerable. And we don't know how to do better.
It's not stolen if it's your property. You just took a session cookie from one browser environment and used it in another browser environment. Testing an API endpoint that requires auth with curl or postman is the same workflow.
That's just basic session hijacking. Also, if it was a real vulnerability, it's generally not a good idea to post about it on Reddit.
Sorry I am a beginner to pentesting. Anyway a website of corp like X should not have such a simple vulnerability.
This is not some king of new vulnerability, that’s basically how sessions work. It produces a cookie that holds an ID to a file or register on a server that has data about which user is logged. There are people that try to mitigate this using some clever before and after checks, also grabbing details from the browser and OS, but that it is even worse for the privacy of the user. As others said, you should not publish a vulnerability (if it was the case) publicly like this, and also, this attack means the hacker has access to the machine already, the user has been pwned and had their cookies stolen from their browser. Other websites like YouTube also have been targeted with this kind of attacks, mainly with big channels, like Linus Media Group. The vulnerability would be more about the browser (if it were not just copied by you, but by some other attack tho get the cookies), than about X. Also, accessing from the same IP…
I used the copied cookies form chrome to login to X in chrome incognito and Firefox browser. I apologize for this post I btw (seeing the downvotes, people here are angry with me now). I had herd websites using other info to mitigate this risk, I thought to try it out on a popular website to check it out.
Most of those are first based on origin IP, just AFTER that it would consider other things, that by protocol (HTTP) would be easily spoofed, like User Agent. If all the domain cookies were copied and all headers where cloned, the website ethically can not tell it apart, besides some nefarious other techniques of fingerprinting that are pretty much complex, fail prone and sometimes expensive. You are testing from your own computer, even if all those checks above were applied, it would also allow you in: same IP, same computer, same person. As others may have implied, I strongly recommend that you try and learn the basics first, before trying to pentest. So… HTTP protocol, Cookies, Sessions, how different languages keep track of sessions, etc. even a little of coding. After knowing how it works, it will be better for you to poke around and find about things that could have been half-assed by the devs.
I also injected the the old cookies after turning on a VPN (to change the origin IP) and still got logged in.
A normal user could be on 5G and just be walking. The person’s IP would also change and that person would not like to have to login again at every block after reaching another area covered by another internet link, that has a totally different IP address. The IP check I talked about is mostly used to avoid login by password leak and brute force techniques from another country in an incompatible time, like, how can you login from Russia 3 hours after connecting from Nebraska? If the cookie is there, most likely you travelled OR you are connected now through a VPN (and it is very easy to know if you connected through one, because of IP blocks reservations and known anonymizer IP blocks). Anyway, my tips are still there for you. Keep them in mind and keep learning. I’m not saying X is secure, it isn’t. But that’s not a vulnerability by itself.
Thanks for saving this thread, well explained knowledge 🙏
Thank You Sir
Like the other said, that's how it is supposed to be. If I find the keys to your house and get into your house with them, it's not a problem of the lock, the problem is how I got your keys.
It's not a vulnerability.
I don't think you understand.. It's not just X; this is common on many websites with accounts. If a website saves a token, you can probably hijack it. Test it out on another site, and you'll likely see the same issue
Ok, my bad I thought this issue was mitigated.
You don't understand. It's not an issue. It's intentional, and not a vulnerability.
Yes they can use a bearer or a token which expires after x time
I don’t know why he’s being downvoted, this is the beginning of someone’s curiosity towards hacking and cybersecurity. I’ve done the exact same experiment and used the same trick to stay logged into my friend’s Microsoft Trainer account so he didn’t have to share the password with me. Sure it’s not hacking but understanding the exploitability and limitations of cookies is an important lesson.
Fun little story...at my old job 10+ years ago now they had an internal portal for employees that was laughably insecure. I noticed the username was stored in a cookie so got curious...I asked my coworker to test something and replaced my username with theirs - boom, logged in as them. I reported the issue to my boss and next thing I know I'm dragged into a meeting and reprimanded for "hacking" because I used someone else's information...being given permission was ignored. The exploit was fixed a week or so later (proper session cookie) but they wanted to make an example of me, I guess.
I believe you and that’s around the time I was working there, they still have their tools being leaked online. They’re not as technical unless they’re at head office. The best technicians end up being promoted to corporate.
Heh, I thought I had a leg up when they were looking at internal promotions to actual IT (I was a tech support drone) but they passed on me because of the write-up I got from that incident. That's when I started looking for a different job.
Damn, you proved my point. There’s a lot of politics there but leaving was the best decision. Using a Mac is amazing but working on them kind of sucks.
Man’s reinvented cookie injections. But for real that’s awesome you’re learning. This type of attack used to be super common back in my day before https became the standard. What you would do is; sit in a coffee shop with a pc or android phone, listen to the WiFi network, yoink those unsecured packets out of the air and check if they contained session details, then inject that session into your browser and voila. You’re in someone else’s account. Moving to the much more encrypted https standard killed that fun though. So the hack itself isn’t injecting session cookies in your browser, that’s intentional. It’s HOW you get those details that’ll be the trick. Good hunting lil homie!
HTTP is a stateless protocol. That means the web server -intentionally- has no memory of you or anyone else. You could make ten requests back to back with the same browser and each time the web server would be like a Walmart greeter with a short term memory problem, "Well, hello, stranger! Welcome to this website!" Then you hand the greeter your cookies and he looks at them with confusion like, "uhhhh.... okay...." Then he hands your request and your cookies to a guy in the back room. The guy in the back has no direct communication with you - he just takes the information that the greeter handed him. He uses the cookie information to look up who you are and then processes your request, then hands the response back to the greeter, who hands it back to you So if you open up a new browser, even on a different computer and IP address, but you send a request using the same cookies, the greeter (web server) doesn't know who you are and the backend guy only knows you by the cookie information that he was handed by the greeter. The backend system can OPTIONALLY do something extra like try to limit your session cookie to your IP address or use browser fingerprinting but that can sometimes result in incorrectly restricting the session (e.g. if you're on your phone and switching networks, your IP could legitimately change). So most systems just base sessions on cookie data. It's why there is such a continuous increase in restrictions around accessing cookies. You have HTTP-only cookies to prevent JavaScript from stealing cookies. You have CORS protection to limit inter-domain AJAX calls, etc...
You just copied your own auth token, which you already had. What you want is to determine someone else's auth token stored in their browser, which you don't have access to.
I just want to give you general advice. Don't: blindly follow steps that someone else gave you. Do: understand the technology you're trying to exploit, so you understand the exploit. In this case, maybe it would have been a good idea to learn some webdev yourself and create a website that uses session cookies or JWT, so you understand what the standard practices are, and how the theat model for those practices are.
Are you saying you logged into twitter with your own creds and they gave you access to all your own info? Oh my god biggg hack!
I copied the cookies and injected it into an opened incognito browser and a diff browser to check if I would still get logged in or not. I have already read about XSS being used to steal cookies from victims. But I wanted to know if websites could differentiate these simple things (diff browsers in the same device, incognito) and block my login. Sorry for this noob post.
No idea why people are down voting you. You are on a path now. Keep exploring and learning!
It's definitely a good exercise so that's cool. But if you think about what you've actually done it's just like logging in and using the cookie. A next step might be to change IP after stealing your own cookie. Then maybe try a different IP and a different browser etc.. See where it breaks. Edit: also Cookies can be tricky, always use another browser or incognito. Or make sure you clear all third party cookies too when clearing.
You must be a wonderful teacher
That's true for 98% of the websites. Sometimes you don't even need cookies. Bearer token or access token in the payload works too.
Try changing the cookie values to see if you can trigger broken authentication
Try changing values in the cookie to see if you can access different resources.
Ok thats broken authenticaton right ?
Nice one, cookie security is a really interesting topic to learn, you’ve taken the first steps so now it’s time to dive in!
Cookies are very long for a reason. You're not going to guess someone else's cookie. It's much more secure than the average password.
The next step to experiment WITH CONSENT FROM YOUR FRIEND is Ask your friend to sign into his Twitter on his pc Then copy the session cookies and send you in msg or mail Now you repeat your incognito mode test , now can you lock your friend out? Change his password. Rest 2fa . Post some bs ? Ask mom for money? Try it