ColdEdge Posted November 5, 2010 Share Posted November 5, 2010 Ok so I made a fully working PHP PM system for my BBS which I am working on. It still lacks ability to attach files but I will get that done sometime soon. Ok so I am in need of some suggestions how to make each users PM secure and prevent un-athorized access to different user PM Inbox.The BBS runs using PHP Sessions. And do to this the PM system uses each user session and compares it to the one in the PM Database.If the user who this message was send to maches his user id which is provided via session then he or she can view this PM. To be double sure random token keys are generated and added to the PM database. So if the token is incorrect the message wont open.Here is how the url looks like inbox.qnx?func=readmsg&mid=115&token=85G9CMQgY4i2my5475GEY9m1a9Gq6MYuGg the original filename is inbox.php but uses .htaccess to rewrite the URL. The script reads the function first which is readmsg meaning open PM. Then the script selects the message id (mid) from the db and finally token is checked this is done truth the URL wille user id is checked in the script truth session.I am now wondering is this trually a secure method to use? Or is there much easier ways that dont require all that token and crap part and can be just as safe? - Thanks in advance, all suggestions are welcomed. Link to comment Share on other sites More sharing options...
jeffman Posted November 5, 2010 Share Posted November 5, 2010 What you're calling a token is just another session cookie. It adds no real security. It can be packet-sniffed with the same amount of ease or difficulty (depending on the cracker) and attacked by brute force with the same amount of ease or difficulty (likewise). Link to comment Share on other sites More sharing options...
ColdEdge Posted November 5, 2010 Author Share Posted November 5, 2010 If I may ask what would be the best way to assure that no data is leaked to members and thouse who want to gain access with out authorization? Link to comment Share on other sites More sharing options...
ColdEdge Posted November 7, 2010 Author Share Posted November 7, 2010 bump... Link to comment Share on other sites More sharing options...
Synook Posted November 7, 2010 Share Posted November 7, 2010 To prevent packet-sniffing and other man-in-the-middle attacks, use HTTPS. With a session ID that long, I wouldn't worry about brute-force attacks too much but the "solution" to that type of attack is just to make it longer.I think what DD is saying is that your extra measures are no more secure than just using the session mechanism by itself. Link to comment Share on other sites More sharing options...
jeffman Posted November 7, 2010 Share Posted November 7, 2010 Just to be clear, are you already protecting against SQL injection? If it's possible that someone could post a javascript that might execute in someone else's browser, are you sanitizing against that? Link to comment Share on other sites More sharing options...
ColdEdge Posted November 7, 2010 Author Share Posted November 7, 2010 All querys are serialized any javascript code is rendered as just text not code. ^^ Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.