Home/ Questions/Q 3608346
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T21:29:23+00:00

Yes hello today I discovered a hack for my site. When you write a

  • 0

Yes hello today I discovered a hack for my site.

When you write a msg on a users wall (in my communitysite) it runs a ajax call, to insert the msg to the db and will then on success slide down and show it.

Works fine with no problem.

So I was rethinking alittle, I am using POST methods for this and if it was GET method you could easily do ?msg=haxmsg&usr=12345679. But what could you do to come around the POST method?

I made a new html document, made a form and on action i set “site.com/insertwall.php” (the file that normally are being used in ajax), i made some input fields with names exactly like i am doing with the ajaxcall (msg, uID (userid), BuID (by userid) ) and made a submit button.

I know I have a page_protect() function on which requires you to login and if you arent you will be header to index.php. So i logged in (started session on my site.com) and then I pressed on this submit button. And then wops I saw on my site that it has made a new message.

I was like wow, was it so easy to hijack POST method i thought maybe it was little more secure or something.

I would like to know what could I do to prevent this hijacking? As i wouldnt even want to know what real hackers could do with this “hole”. The page_protect secures that the sessions are from the same http user agent and so, and this works fine (tried to run the form without logging in, and it just headers me to startpage) but yea wouldnt take long time to figure out to log in first and then run it.

Any advices are appreciated alot. I would like to keep my ajax calls most secure as possible and all of them are running on the POST method. What could I do to the insertwall.php, to check that it comes from the server or something..

Thank you

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Based on your comment…

    Anything outside your server is outside your control. You must define what you want to let in at the border of your server, and not in the browser.

    So, for example, if you want to let people send messages, then any restrictions you want to impose (only logged in users, only to friends, only when the moon is waxing, etc) must be imposed on the server.

    What you send to the browser can be thought of as an application that interacts with your API. People might interact with your API in ways that you don’t expect, but you are safe if all your security is taken care of by the server.

    (Until we come onto the subject of man in the middle stuff, in which case look into CSRF prevention and encryption with SSL)

    • 0