What else can I do?
For an administrative backend for one of my sites, to secure it against cookie theft, I have created a session_id cookie that is created with 40 completly random characters all being thrown together in a base64(sha1(md5())) combo, it is then stored in my mysql database, after being stripped for html tags and mysql special characters, and locked to the current users ip address, which is also stored in the database after receiving the same treatment as the session_id. Finally, my final protection is against bruteforcing, if the IP is not in a my whitelist of IP addresses and I recieve more than 5 bad login attempts, then they are added to a blacklist, never allowed to even try to login unless I go in and approve.
All IP addresses are encrypted and have html and mysql special chars stripped out of them, as does all the other data that gets put in my database.
I guess my question is really, is there anything else I can do to make this page secure? I've covered, at least to some extent, xss, cookie theft, sql injection, and bruteforcing. Is there something I missed? Or something I could do better?
edit If there are any suggestions you have, it is best to avoid creating any hassles for the end user as this page is for someone else
Thanks wired_al
Question time!
wired_al wrote: to secure it against cookie theft, I have created a session_id cookie that is created with 40 completely random characters What's wrong with PHP's session handling?
wired_al wrote: all being thrown together in a base64(sha1(md5())) combo, it is then stored in my mysql database, after being stripped for html tags and mysql special characters After the md5, sha1 and base64, do you really think there will be anything dangerous left in the input? What's the need for stripping html tags and mysql special characters?
wired_al wrote: All IP addresses are encrypted and have html and mysql special chars stripped out of them, as does all the other data that gets put in my database. Again, why do you need to strip special characters out of an IP address (especially after it's been encrypted)?
wired_al wrote: if the IP is not in a my whitelist of IP addresses and I recieve more than 5 bad login attempts, then they are added to a blacklist, never allowed to even try to login unless I go in and approve. If you want to avoid creating hassles for the end user, you might want to ease these restrictions a bit. It could lock a legitimate user out.
starofale wrote: Question time!
[quote]wired_al wrote: to secure it against cookie theft, I have created a session_id cookie that is created with 40 completely random characters What's wrong with PHP's session handling? [/quote]
Nothing really, I haven't had experience using it so I don't know how to check it against a value in my database.
starofale wrote: [quote]wired_al wrote: all being thrown together in a base64(sha1(md5())) combo, it is then stored in my mysql database, after being stripped for html tags and mysql special characters After the md5, sha1 and base64, do you really think there will be anything dangerous left in the input? What's the need for stripping html tags and mysql special characters? [/quote]
I don't really think it is needed, but I do know that I have been bit before for assuming that some things are safe when they are not a few years ago. All data is put through sanitation that goes into my database by default just so I don't forget on something.
starofale wrote: [quote]wired_al wrote: All IP addresses are encrypted and have html and mysql special chars stripped out of them, as does all the other data that gets put in my database. Again, why do you need to strip special characters out of an IP address (especially after it's been encrypted)? [/quote]
I have read that using tools like cURL that it is possible to spoof IP addresses and figured that if I didn't secure it (before encryption of course) that someone who wanted in could change their IP address to use SQL injection to access the site. After encryption, again it's just my default methods cleaning up everything that goes in.
starofale wrote: [quote]wired_al wrote: if the IP is not in a my whitelist of IP addresses and I recieve more than 5 bad login attempts, then they are added to a blacklist, never allowed to even try to login unless I go in and approve. If you want to avoid creating hassles for the end user, you might want to ease these restrictions a bit. It could lock a legitimate user out.[/quote]
Well, this page is for the admin panel for my site, so there is only really 1 legitimate user so I am not too concerned about someone being locked out who is legitimate.
This site is for someone else, not quite sure what they want to do with it, they never told me, so I figured I would secure it like I would for any other site just in case he wound up doing something important for it and maybe improve my methods a little bit.
Thanks wired_al
starofale wrote: If you want to avoid creating hassles for the end user, you might want to ease these restrictions a bit. It could lock a legitimate user out. The way I understood it he'd be blocking the IP from where the attempts came, not the account itself. That shouldn't create any feasible problems for any user.
wired_al wrote: I have read that using tools like cURL that it is possible to spoof IP addresses and figured that if I didn't secure it (before encryption of course) that someone who wanted in could change their IP address to use SQL injection to access the site. What?
All data is put through sanitation that goes into my database by default just so I don't forget on something. Don't you think that it might be better to carefully put together a script where you know what comes from where and how it is handled, rather than just throwing everything at everything blindly?
COM wrote: [quote]starofale wrote: If you want to avoid creating hassles for the end user, you might want to ease these restrictions a bit. It could lock a legitimate user out. The way I understood it he'd be blocking the IP from where the attempts came, not the account itself. That shouldn't create any feasible problems for any user. [/quote] Yes that is correct.
COM wrote: [quote]wired_al wrote: I have read that using tools like cURL that it is possible to spoof IP addresses and figured that if I didn't secure it (before encryption of course) that someone who wanted in could change their IP address to use SQL injection to access the site. What? [/quote]
I don't remember where I read it, but I had read that you could use, and I don't remember for 100% sure, but I really want to say it was cURL, to sppof your IP address. So if someone put their ip to xxx.xxx.xx.x'; DROP TABLE table– or something like that it could have been used to wreak havoc on my site. I decided that the IP addresses in the database that were locked out would be encrypted just so they couldn't do something like that. Also, the IP addresses that go in the users table are encrypted to protect the user just in case they manage to get into my database.
COM wrote: [quote]All data is put through sanitation that goes into my database by default just so I don't forget on something. Don't you think that it might be better to carefully put together a script where you know what comes from where and how it is handled, rather than just throwing everything at everything blindly?[/quote]
Well, not all information is encrypted, only what I feel could be a potential threat to my site or the end user should the information be leaked, but all the variables (username, password, IP address) that get stored into my site has html and mysql strings stripped.
If anyone has any ideas, I would really like to hear them, and thanks starofale and COM for the constructive criticism.
Thanks wired_al
wired_al wrote: I don't remember where I read it, but I had read that you could use, and I don't remember for 100% sure, but I really want to say it was cURL, to sppof your IP address. So if someone put their ip to xxx.xxx.xx.x'; DROP TABLE table– or something like that it could have been used to wreak havoc on my site. I decided that the IP addresses in the database that were locked out would be encrypted just so they couldn't do something like that. Also, the IP addresses that go in the users table are encrypted to protect the user just in case they manage to get into my database. You misunderstood me, what I meant was: You do realise that the ip that you get is a string representation of a value of no more than four bytes [ipv4] in the IP header of the request sent to the server? It's literally just an int, four octets with values from 0 to 255. It is only then translated into a string representation of the decimal values of each octet separated by dots for ease of reading. You literally cannot send a string as an IP. And if you would, it'd be a four character long string and you would get the numerical values of the characters, not the originally used string.
COM wrote: You misunderstood me, what I meant was: You do realise that the ip that you get is a string representation of a value of no more than four bytes [ipv4] in the IP header of the request sent to the server? It's literally just an int, four octets with values from 0 to 255. It is only then translated into a string representation of the decimal values of each octet separated by dots for ease of reading. You literally cannot send a string as an IP. And if you would, it'd be a four character long string and you would get the numerical values of the characters, not the originally used string.
Oh, ok. I didn't know that. So there is literally no way possible for someone to perform SQL injection via IP address? I've just started viewing everything sent from the user as a potential threat as much as I can without hassling the end user.
Thanks wired_al
Okay, Christ. Stop, stop, stop, stop, stop.
99.99% of the time someone tries to implement their own version of something that has already been implemented for years and tested by thousands of developers, they fuck it up big time in comparison. This is one of those cases.
Using cookies is a terribly bad idea here, learn how to use PHP sessions and save yourself a ton of time and effort. Literally everything you are doing (except the blacklisting) could be ignored and instead done with about 5 lines of PHP code if you used sessions.
Please, just use sessions, you will thank yourself later on. And no, there is no way to send SQL injections through the I.P address.
stealth- wrote: Using cookies is a terribly bad idea here, learn how to use PHP sessions and save yourself a ton of time and effort. Literally everything you are doing (except the blacklisting) could be ignored and instead done with about 5 lines of PHP code if you used sessions.
Please, just use sessions, you will thank yourself later on.
Wow, you are right. I really wish I had heard of them before yesterday… (yeah I'm kind of ignorant, but that can happen when you teach yourself)
Thanks everyone for the help. I switched to sessions last night and it's lots simpler. If anyone has any other suggestions, please post them and I will look at them and see if its something I can do.
Thanks wired_al
wired_al wrote: Why not? Just out of curiosity. And what kind of encryption would you recommend?
Thanks wired_al
Stacking encryptions means you're increasing the amount of collisions considerably. MD5 is outdated and broken, you're better off using the standard like AES(-256).
Like stealth- said, don't do crypto yourself, use a lib/software that others developed.
I would use sha512. use the link below to help you understand how to use sha512.
http://uk3.php.net/manual/en/function.hash.php
{
return hash('sha512', $value);
}```