Is it possible to give POSTs to a page without being in the code? You can give GETs by just doing ?[GetName]=[GetValue], but is it possible in some way to add POSTs to a page, without accessing the code?
Please let me know!
Thanks!
POSTs
No, probably not, but it depends on what you mean with 'the code'. How do you plan to send these posts?
If you are writing a program then you can certainly send posts to a page that you didn't create yourself, but you can't send them from the browser address-bar.
If you are writing a program then you can certainly send posts to a page that you didn't create yourself, but you can't send them from the browser address-bar.
Author
That's something I know, of course. I know you can't set POSTs by URL. But isn't there some kind of way / program or anything that let's you send in POSTs to a page? You can't send POSTs by URL, so it's a safer way then to work with GETs. But I'm testing the how safe POSTs are now. I thought I heard of a way to send POSTs with a web page once, but can't remember how exactly.
Thanks!
Thanks!
Safe for what?
Someone can certainly send you a POST request without going through the web-page you intend to be the source.
Someone can certainly send you a POST request without going through the web-page you intend to be the source.
Quote:Original post by MarlyBut I'm testing the how safe POSTs are now. I thought I heard of a way to send POSTs with a web page once, but can't remember how exactly.
POST requests are exactly as secure as GET requests - ie. not at all. Parameters in a POST request may not be visible in the url, but it's trivial to add/remove/change them with a custom client (or even a suitable browser plugin).
Do not use POST vs. GET for 'security' reasons or to try and stop people tinkering with your parameters. Use GET when your request is idempotent, and POST if it not (or one of the other non-idempotent request types if it's more suitable). If you don't do this then web caches, proxies and the like may screw up your app by giving your old/incorrect data that you weren't expecting.
Author
I'll try to explain what I mean. I'm not that good at English so I try my best.
I am making a website that uses GET's to load a certain page. When you publish something it uses a GET, but finally it uses POSTs etc. to send to the server what your username is, your user_id, etc. Let's say it sends..
POSTs:
username = marly
user_id = 14328
How could I manage to publish and send the POSTs I like myself?
Let's say I would like to send
username = roger
user_id = 13224
Without actually being user roger with that ID?
I hope you understand my question better now.
@OrangyTang
What kind of browser plugins are examples of that then? Because that is exactly my question. I am not trying to check the safety differences between GETs and POSTs, just here to see how you can change the given POSTs, because for GETs that is kinda simple. Just change the URL.
Ty!
I am making a website that uses GET's to load a certain page. When you publish something it uses a GET, but finally it uses POSTs etc. to send to the server what your username is, your user_id, etc. Let's say it sends..
POSTs:
username = marly
user_id = 14328
How could I manage to publish and send the POSTs I like myself?
Let's say I would like to send
username = roger
user_id = 13224
Without actually being user roger with that ID?
I hope you understand my question better now.
@OrangyTang
What kind of browser plugins are examples of that then? Because that is exactly my question. I am not trying to check the safety differences between GETs and POSTs, just here to see how you can change the given POSTs, because for GETs that is kinda simple. Just change the URL.
Ty!
POSTS are almost as simple as GET. Read the HTTP RFC.
You can write anything in a post by interacting with the server through telnet. Anything on top of that just makes it easier, but the basic attack is the same from the server's perspective.
If you want to protect the content sent and received, use HTTPS. If you want to prevent unathorised clients acting as authorised ones, you must ensure that each request includes something which indicates the client is authorised. This could be as simple as HTTP BASIC authorisation, or a securely generated cookie which indicates that this client has recently sent the server the correct username/password.
The critical thing is that the client never says "I'm user X" or "I'm an admin". It says, "I'm user X, here is proof" or "Here is a token you gave me earlier, find out who I was then".
This isn't 100% effective, but its "good enough" for many uses. Cookies are how a site like gamedev.net work, you cannot impersonate me because I can only obtain a "rip-off" cookie by logging in with a password you don't know. The server uses this cookie to determine my user id. It is infeasible for you to guess my password or cookie. However, if you were on my local network you could sniff my password, because gamedev.net does not offer HTTPS for logging in.
For a more "serious" site, HTTPS would really have to be offered, at least for logging in. Arguably, gamedev.net should use HTTPS because some of us have accounts we have paid for, and have an actual value in the real world. I believe v5 will support it, but its been a long time coming.
You can write anything in a post by interacting with the server through telnet. Anything on top of that just makes it easier, but the basic attack is the same from the server's perspective.
If you want to protect the content sent and received, use HTTPS. If you want to prevent unathorised clients acting as authorised ones, you must ensure that each request includes something which indicates the client is authorised. This could be as simple as HTTP BASIC authorisation, or a securely generated cookie which indicates that this client has recently sent the server the correct username/password.
The critical thing is that the client never says "I'm user X" or "I'm an admin". It says, "I'm user X, here is proof" or "Here is a token you gave me earlier, find out who I was then".
This isn't 100% effective, but its "good enough" for many uses. Cookies are how a site like gamedev.net work, you cannot impersonate me because I can only obtain a "rip-off" cookie by logging in with a password you don't know. The server uses this cookie to determine my user id. It is infeasible for you to guess my password or cookie. However, if you were on my local network you could sniff my password, because gamedev.net does not offer HTTPS for logging in.
For a more "serious" site, HTTPS would really have to be offered, at least for logging in. Arguably, gamedev.net should use HTTPS because some of us have accounts we have paid for, and have an actual value in the real world. I believe v5 will support it, but its been a long time coming.
Quote:Original post by Marly
@OrangyTang
What kind of browser plugins are examples of that then? Because that is exactly my question. I am not trying to check the safety differences between GETs and POSTs, just here to see how you can change the given POSTs, because for GETs that is kinda simple. Just change the URL.
TamperData came up on the first page of a google search, and looks like what you're looking for. I'm sure there are similar things for other browsers too, as it's quite a trivial task.
I'd second rip-off's suggestion of reading through the HTTP spec to get a better idea of how things work under the hood. Another good approach would be to install WireShark and start sniffing the traffic your browser is sending.
The differences between post and get is get requests are encoded into url query.
Post is embed into the page request header. The only useful thing about post is the data will not be stored in url history in your browser. Makes it a good option for long forms. But it is no more secure than get but its a little harder for a avenger user to mess with.
What i do is that i use post for data which i intend to store. Get queries i use for navigation and searches things of that nature. if the user may want to bookmark it then use get otherwise post.
Post is embed into the page request header. The only useful thing about post is the data will not be stored in url history in your browser. Makes it a good option for long forms. But it is no more secure than get but its a little harder for a avenger user to mess with.
What i do is that i use post for data which i intend to store. Get queries i use for navigation and searches things of that nature. if the user may want to bookmark it then use get otherwise post.
Quote:Original post by bythosThe other benefit of POST is that google-bots wont hammer all your POST requests. Google-bots will happily call all your GET requests, so make sure that anything callable via GET is secured against random calls.
But it is no more secure than get but its a little harder for a avenger user to mess with.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement