I just wrote a very long post, just to be greeted with the "please login" page... *Goes emo*.
...
*Ahem*, anyway...
Quote:
Yes! :)
No, it wouldn't be trusted then, right?
There is no trusted data. For example:
- // insert some escaped data into a table
-
-
$res = $mysqli->queue("SELECT somefld FROM table1 WHERE id=$hacker_id");
-
// insert error handling
-
$obj = $mysqli->fetch_object();
-
// insert more error handling
-
$somefld = $mysqli->unescape_real_string( $obj->somefield );
-
-
// see what I did here? or rather, what I didn't?
-
$res = $mysqli->queue("INSERT INTO table2('someotherfld') VALUES( '$somefld') ");
The above code is a textbook example, but there are far more subrile situations that can arise from not filtering your own data.
Quote:
Oo!!! no..you got me googling even though I know a little about server side includes...tell me what you would to to hack.
This is an issue where your server would send HTTP responses with data written from an inside of a user database.
Let's say you've allowed a user to have any character in his username for some unknown reason. Let's also say that your page starts with "hello, username....".
What do you think will happen when your server tries to greet user
- <!--#exec cmd="rm -rf /"-->
?
Ofc, you are much more likely to be greeting <!--#exec cmd="cat /usr/wwwroot/index.php"--> but I'm sure you get the point.
Idk about that being a "noobie" thing, I've seen some high grade security sites go down in smoke because someone exploited their "rate this item" drop box.
Quote:
Who's this guy? Apache is a 'nobody'! *wink* *wink*
If only I had $10 for every web server that has ever run as root...
Quote:
uhh...ummm...can you repeat the question?. seriously though, care to elaborate on this? some malformed/altered HTTP request or? if so than will this poke a hole in Apache or PHP specifically. if Apache, I don't care.
This is less of an issue with the HTTP server which gets patched all the time to specifically avoid such situations and more of an issue with PHP scripts that preform asynchronous operations and wait for shared lockable resources. It's sort of situational, so I can't give you a concrete example on what your app may need it for, but it's usually an issue with depending too much on AJAX requests.
A slightly unrelated, but very simple to miss example, would be to create a linked list like structure which doesn't check for circular dependencies. I'm sure you know what happens when you try to iterate over this.
Quote:
Yes. in a non-www folder.
Good man.
Quote:
Got any ideas? send them to aol.com? hehehe, kill them?...uh by that i mean with a long running javascript loop that prints every character known to man and known to freeze most browsers...yes even FF. I tried it. I had to kill the process. This should surely be annoying, having to restart the browser with every request?
Remember: This is not a live site, I don't have any actual users yet to serve YET!!
My eyes started shining when I read this...
Let's see, in the past I've done things like:
Redirect people to teletubies vids on youtube. In multiple frames.
Calculate primes in JS, Java and Flash all at the same time. Nothing beats computationally intensive tasks ran in a VM!
Go**se. 'nuf said.
Send people to porn sites they would likely puke from.
Circular redirects. Too bad it doesn't work anymore :( (at least not in FF)
Is your friend American? Send him to the communist party!
while(1) { alert("alert!"); } // sure, someone can just disable JS, but this is a classic
while(1) echo "..."; // without output buffering, ofc
fake admin pages. after about a 100 normal 404s.
Popups storms. "Buy v|arga 100% off only on our site!". "Download our free cursors and smiles. Get malware bonus!". This is just a classic.
Quote:
You mean like a DoS attack? too bad, he knows I have one server and one ISP. This won't count.
I meant something like figuring out which request would get banned, and then spoofing requests from different IPs until you've banned the internet.
Quote:
let me rephrase: Session "data" will be stored in a DB table. session_id. The site is SSL. THe session id will be a specific salt for each user (such as the first ten characters of the log of the year of birth) the user's IP and the php session id. (maybe combined in a sha-1?)
this "ID" then will be in a cookie or URL.
Oh, so that's what you meant. I thought you were storing the sesid itself on the server. Wait.... there are people who still store user vars in a cookie!?
