Join us at IRC!
Society leans ever heavily on computers, if you have the power to take out computers you can take out society. - cubeman372
Friday, May 25, 2012
Navigation
Members Online
Total Online: 32
Web Spiders: 16
Guests Online: 30
Members Online: 2

Registered Members: 70220
Newest Member: borsche_1110
Latest Articles
View Thread

HellBound Hackers | Computer General | Webmasters Lounge

Author

What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 13-06-11 17:51
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

Edited by wired_al on 13-06-11 18:18
Author

RE: What else can I do?

starofale
Member



Posts: 213
Location: England
Joined: 05.12.07
Rank:
God
Posted on 13-06-11 21:57
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.


Try a new search engine

Edited by starofale on 13-06-11 22:00
Author

RE: What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 13-06-11 22:35
starofale wrote:
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?


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:
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?


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:
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)?


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:
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.


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
Author

RE: What else can I do?

COM
Banned



Posts: 800
Location:
Joined: 31.08.07
Rank:
God
Posted on 13-06-11 23:52
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 scblockedript where you know what comes from where and how it is handled, rather than just throwing everything at everything blindly?


K'aem'nhi kh'rn, K'aem'nhi kh'r, K'aem'nhi kh'rmnu.
I'a Y'gs-Othoth!
Author

RE: What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 14-06-11 00:53
COM wrote:
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.

Yes that is correct.

COM wrote:
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?


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:
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 scblockedript where you know what comes from where and how it is handled, rather than just throwing everything at everything blindly?


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

Edited by wired_al on 14-06-11 00:54
Author

RE: What else can I do?

COM
Banned



Posts: 800
Location:
Joined: 31.08.07
Rank:
God
Posted on 14-06-11 01:09
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.


K'aem'nhi kh'rn, K'aem'nhi kh'r, K'aem'nhi kh'rmnu.
I'a Y'gs-Othoth!
Author

RE: What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 14-06-11 01:13
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
Author

RE: What else can I do?

stealth-
Member



Posts: 999
Location: Eh?
Joined: 10.04.09
Rank:
God
Posted on 14-06-11 05:52
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.


The irony of man's condition is that the deepest need is to be free of the anxiety of death and annihilation; but it is life itself which awakens it, and so we must shrink from being fully alive.
http://www.stealth-x.com
http://www.stealth-x.com
Author

RE: What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 14-06-11 18:30
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
Author

RE: What else can I do?

spyware
Member



Posts: 4190
Location: The Netherlands
Joined: 14.04.07
Rank:
God
Warn Level: 90
Posted on 14-06-11 19:38
Don't stack encryptions. Ev-er. Also don't use md5. Ev-er.




"The chowner of property." - Zeph
“Widespread intellectual and moral docility may be convenient for leaders in the short term,
but it is suicidal for nations in the long term.”
- Carl Sagan
“Since the grid is inescapable, what were the earlier lasers about? Does the corridor have a sense of humor?” - Ebert
http://bitsofspy.net
Author

RE: What else can I do?

wired_al
Member

Posts: 16
Location:
Joined: 03.04.10
Rank:
Active User
Posted on 14-06-11 19:57
spyware wrote:
Don't stack encryptions. Ev-er. Also don't use md5. Ev-er.


Why not? Just out of curiosity. And what kind of encryption would you recommend?

Thanks
wired_al
Author

RE: What else can I do?

spyware
Member



Posts: 4190
Location: The Netherlands
Joined: 14.04.07
Rank:
God
Warn Level: 90
Posted on 14-06-11 20:53
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.




"The chowner of property." - Zeph
“Widespread intellectual and moral docility may be convenient for leaders in the short term,
but it is suicidal for nations in the long term.”
- Carl Sagan
“Since the grid is inescapable, what were the earlier lasers about? Does the corridor have a sense of humor?” - Ebert
http://bitsofspy.net
Author

RE: What else can I do?

Mordak
Evil Sorcerer



Posts: 437
Location: England
Joined: 01.01.70
Rank:
Wiseman
Posted on 16-06-11 02:33
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

function sha512($value)
{
return hash('sha512', $value);
}



Author

RE: What else can I do?

spyware
Member



Posts: 4190
Location: The Netherlands
Joined: 14.04.07
Rank:
God
Warn Level: 90
Posted on 16-06-11 17:18
Mordak wrote:
I would use sha512. use the link below to help you understand how to use sha512.


For hashing, use this (SHA), for encryption, use AES.




"The chowner of property." - Zeph
“Widespread intellectual and moral docility may be convenient for leaders in the short term,
but it is suicidal for nations in the long term.”
- Carl Sagan
“Since the grid is inescapable, what were the earlier lasers about? Does the corridor have a sense of humor?” - Ebert
http://bitsofspy.net
Guest
Username

Password

Remember Me


Bookmark This Page
Affiliates
Adverts

 

 

Links
By using, viewing or obtaining any information contained on this site, you agree to the disclaimer.

© HellBound Hackers 2008- 2009. Since 3rd December 2004.