pic related

___________________

Exactly the kind of thing I had in mind when I posted this thread

___________________
Indiana Clones Upcoming Sets
[ I May Upload Something Someday ]

Tough call Lira, but I would recommend turning on your Windows Firewall immediately.

___________________

Windows Firelol

___________________

quote:

Originally posted by OrangestO This isn't about physics, this is about waves.

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

___________________
Nothing to see here

You should use Firefox and Windows 7.

___________________
-~-

And, Stu, the files are on a server in Virginia, not on my computer

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

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.

___________________
Indiana Clones Upcoming Sets
[ I May Upload Something Someday ]

quote:

Originally posted by Lira And, Stu, the files are on a server in Virginia, not on my computer 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 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); )

___________________
Nothing to see here

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!

___________________
Nothing to see here

Learn PDO (waiting for a pedo joke), that's PHP data objects.

http://www.phpro.org/tutorials/Intr...to-PHP-PDO.html

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.

Last edited by *** on Mar-03-2012 at 10:26