|
Need advice on web security
|
View this Thread in Original format
| Lira |
I'm currently developing a language database for my PhD studies and, because this could be of great use to people all over the world, I'd like to make it freely available on the net once I'm done with it. The problem is: even if you're well-intended, that doesn't mean no one will try to hack your website at one point or another... and I should get the bastard shield ready before script kiddies of all sorts decide to wreak havoc and vandalise the website.
All the information is stored on a MySQL database and accessed via PHP. What precautions do I have to take in order to protect the data? I know I should (and I intend to) read more about web security, but I'd like to have the opinion of some experts first :) |
|
|
| netroM |
pic related |
|
|
| Lira |
:stongue:
Exactly the kind of thing I had in mind when I posted this thread :p |
|
|
| Sushipunk |
| Tough call Lira, but I would recommend turning on your Windows Firewall immediately. |
|
|
| srussell0018 |
| Windows Firelol |
|
|
| FuzzQi |
These functions here are good for wrapping around any variables that get passed to the database.
addslashes()
mysql_real_escape_string()
real_escape_string()
str_replace()
They stop things like SQL injection attacks
Don't use $_REQUEST over $_SESSION, $_GET or $_POST, it's a vulnerability (session variable could get overwritten by the haxxor putting ?variable=value in the url)
Store whatever you can of your procedures outside of the site's web root and link to them in your live pages by using require() or include(). If PHP crashes, these pages will be sent to the browser as plain text and you generally don't want php code to be seen by the visitor.
Don't rely on $_POST variables to be secure. Although they don't seem to be as manipulable as $_GET thanks to things like Tamper Data you can edit anything sent in a request header!
Will try to think of a few more if they come to me  |
|
|
| aquila |
| You should use Firefox and Windows 7. |
|
|
| Lira |
:stongue:
And, Stu, the files are on a server in Virginia, not on my computer :p
| quote: | Originally posted by FuzzQi
These functions here are good for wrapping around any variables that get passed to the database.
addslashes()
mysql_real_escape_string()
real_escape_string()
str_replace()
They stop things like SQL injection attacks |
I've been using the second one quite consistently thus far... is it enough to avoid people tampering with the database?
| quote: | Originally posted by FuzzQi
Don't use $_REQUEST over $_SESSION, $_GET or $_POST, it's a vulnerability (session variable could get overwritten by the haxxor putting ?variable=value in the url) |
Note taken :)
| quote: | Originally posted by FuzzQi
Store whatever you can of your procedures outside of the site's web root and link to them in your live pages by using require() or include(). If PHP crashes, these pages will be sent to the browser as plain text and you generally don't want php code to be seen by the visitor. |
I was already doing it because I found it easier to edit several tiny files than one giant file. Nice to know it's got more advantages :p
| quote: | Originally posted by FuzzQi
Don't rely on $_POST variables to be secure. Although they don't seem to be as manipulable as $_GET thanks to things like Tamper Data you can edit anything sent in a request header! |
Hhmm... this could turn out to be a vulnerability. I'm using AJAX throughout the site, with loads of $_GET variables, so although the requests don't ever show up in the address bar, someone can just snoop around the javascript files and manipulate the variables.
Hmm... I wonder how I can sort this problem out. |
|
|
| FuzzQi |
| quote: | Originally posted by Lira
:stongue:
And, Stu, the files are on a server in Virginia, not on my computer :p
I've been using the second one quite consistently thus far... is it enough to avoid people tampering with the database?
|
Never hurts to over prepare for that! I would add on a regex with str_replace() to filter out things explicitly.| quote: |
Note taken :)
I was already doing it because I found it easier to edit several tiny files than one giant file. Nice to know it's got more advantages :p
Hhmm... this could turn out to be a vulnerability. I'm using AJAX throughout the site, with loads of $_GET variables, so although the requests don't ever show up in the address bar, someone can just snoop around the javascript files and manipulate the variables.
|
You can also send $_POST with AJAX, but your best bet is to validate all of the variables sent on the processing page. | quote: |
Hmm... I wonder how I can sort this problem out. |
Another one that I do: have 2 id fields in your database tables, the first one is ID as an integer, the second is a hash of that ID using a message digest like md5() plus a salt (e.g. $hash_id=md5("owiujnaeha0p8we0fafe".$id); ) |
|
|
| FuzzQi |
| Oh yeah the point of that last one is so if you do send any IDs to the browser (page.php?id=3 for example) you can then send hashes instead, it's way trickier to decode. Looking it up isn't any more difficult than looking up an ID in the database. Just don't use no salt (md5($id)) because everyone knows how to unhash a normal integer! |
|
|
| *** |
| quote: | Originally posted by Lira
...developing a language database for my PhD...
...***worried about being hacked***...
What precautions do I have to take in order to protect the data? |
1. Don't connect your database to the internet.
2. Use an interface that is non standard.
3. Have a offline backup for your secure system in lead and a faraday cage buried somewhere and possibly encased in concrete. with land mines and IED's and lethal radioactive material nearby. Saying do not enter, No solicitations, Trespassers will be undertaken.
4. You want to encase all your systems in farraday mesh. Make sure you have have explosives or radioactive materials - combined with fletchettes punjii sticks. Consider posting lots of porn on the walls too just to throw a would be attacker off guard. Throwing in a sex doll in the same room with the server may throw off the average script kiddie.
5. Don't use windows, or mac, or any operating system that is known.
6. Use your own File System, not a known file system.
7. Do not use any standard equipment, consider 9 bit servers and trinary systems operated by gears containing oscillated crystals rather than magnetics.
8. Assemble pages rather than have them ready made or standardized.
9. Do not take any inputs other than your allowed inputs close off all other interface types.
10. Serve your data from major servers that are not succeptable to ddos attacks.
11. Ban all IP's of non subscribed people to your server access. require a sign up with a specific IP. create a proxy with some other method of login such as facial recognition or subscribe by MAC.
These are some ideas.
The key is to build everything from the ground up...read abit about TEMPEST .. you can't use an electromagnetic system if you want to avoid being hacked. You can only defend if you have enough resistance to protect against an external EW takeover of your system.
All devices can be controlled externally via EW tech
Realize the internet is an EM system so it is always succeptable to takeover via EW.
The only resistance is EW hardening via tempest methodologies and non standards based engineering. example don't use the most efficient systems. Do not program in english and bloat your system, also don't use regular math and make your own os that implements symbolic visual programming in a non standard ex. the trinary or quad or quantum based operating environment, that is mechanical and is fluid rather than a static system. |
|
|
|
|
