|
fletcher posted:Just use PDO and avoid creating Yet Another Layer. Whether it's msyqli prepared statements or PDO prepared statements it's the same issue. Every time you use one there's a bunch of repeated code. Best to have that in one spot -- like, say, in a database class -- instead of scatter all over the application, no? That way if you wanted to, you know, switch from mysqli to PDO you only have to change code in one place.
|
#
?
Jun 24, 2010 19:59
|
|
|
|
| # ? Jun 4, 2024 04:36 |
|
|
JasonV posted:Whether it's msyqli prepared statements or PDO prepared statements it's the same issue. And in doing so you throw out all the performance benefits of using a prepared statement. For a simple application, using PDO will allow you to switch database vendors fairly easily. For everything else, there will be a ton of work involved in changing database vendors anyways.
|
|
#
?
Jun 24, 2010 20:22
|
|
|
I have a question about prepared statements... I am learning how to use prepared statements and get away from old queries. The one thing i've run into is mysql_insert_id. I will insert data into a table and then get the id of that last insert to use in a different table. Specifically when creating a new user, I'll insert the user info into the users table and then insert detailed info about the user into another table with the id. I would always use $id = mysql_insert_id(); to get the ID. I've read that using PDO there is a very similar function but I've also read not to use it because it really only works witn MySQL, but even then can cause issues. $id = $DB->lastInsertId(); Is there a preferred method for doing what I am trying to do without doing extra queries to select the id from the database using the username or some other unique value to be sure to get the proper id?
|
|
#
?
Jun 24, 2010 20:38
|
|
|
DarkLotus posted:Is there a preferred method for doing what I am trying to do without doing extra queries to select the id from the database using the username or some other unique value to be sure to get the proper id? Yeah I have always avoided lastInsertId and instead just issue another query to grab the id for whatever was just inserted. Bit of a pain in the rear end, but it works.
|
|
#
?
Jun 24, 2010 20:45
|
|
|
fletcher posted:Yeah I have always avoided lastInsertId and instead just issue another query to grab the id for whatever was just inserted. Bit of a pain in the rear end, but it works. I figured that is the most compatible way of doing it but thought since PDO is so awesome there must be a more efficient way.
|
|
#
?
Jun 24, 2010 21:00
|
|
|
Recently, I "inherited" a website, and, at least temporarily, I'm responsible for keeping the pages up to date while the company I work for looks for a permanent employee. A case of "well, he's done it in the past, so he can do it until then..." A recent security audit of the website has shown a vulnerability to javascript injections. I traced it down to a particular file, and unfortunately, it's a short php file that is included in nearly every page of our site. It pretty much just contains the following: code:So I hunt down a decent regex for php that might do some basic sanity checking and update the code to: code:FuzzyBuddha fucked around with this message at 23:31 on Jun 24, 2010 |
|
#
?
Jun 24, 2010 23:28
|
|
|
Plorkyeran posted:You can't. HTTP redirects only support GET and HEAD. Stick the data in the session or something. Thanks. I'll do that carefully.
|
|
#
?
Jun 25, 2010 00:02
|
|
|
FuzzyBuddha posted:
I don't really see the security hole here, since the value stored in $_GET['print'] isn't actually used. Maybe it throws an undefined index warning? That would be fixed with code:
|
|
#
?
Jun 25, 2010 01:12
|
|
|
FuzzyBuddha posted:
I'm a bit confused here. Are you passing in a bunch of HTML in through the url? And you want to prevent naughty bits of HTML from getting through?
|
|
#
?
Jun 25, 2010 01:21
|
|
|
fletcher posted:I'm a bit confused here. Are you passing in a bunch of HTML in through the url? And you want to prevent naughty bits of HTML from getting through? One of two things occurs: either nothing is passed in the URL or "print=true" is being passed. Based on this, this php file chooses which template to utilize. What we found is if you append the url to pretty much any page with something like: ?"><script>alert('test')</script> then the script gets executed. My guess is, it's because of this small php script, as no other include file seems to deal with $_GET at all... EDIT - Hmmm, I lied... Looks like another include does a $_SERVER['REQUEST_URI'] that does no sanity checking, either... FuzzyBuddha fucked around with this message at 01:56 on Jun 25, 2010 |
|
#
?
Jun 25, 2010 01:41
|
|
|
Blacklisting is generally a bad idea since it can be computationally expensive and difficult to keep current. The best way to approach data sanitisation for Cross-Site Scripting is to encode the tainted data with HTML entities before it is output. If this data is not being used in database queries etc and is simply reflected, just use htmlentities() to encode the data when it is output. Check out the OWASP ESAPI for PHP too, it provides a bunch of encoding, data validation, access control, etc functionality.
|
|
#
?
Jun 25, 2010 02:10
|
|
|
snare posted:... Wow. That did it.  No, the data's not being sent to a database, so gave that a shot with the second include and it fixed the issue across the site. Also, thanks for the references. I can't believe how rusty I've gotten with this.
|
|
#
?
Jun 25, 2010 02:35
|
|
|
Speaking of security: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2225 Stefan Esser posted:The 0-day I showed at SyScan Singapore was a use-after-free vulnerability in PHP's unserialize().Unserializing user input==remote code exec. Stefan Esser posted:The exploitation path I demoed at SyScan will only work against non Suhosin protected servers. More complicated exploits allow to bypass Suhosin. A lot of php applications use unserialize on user input. Edit: I spoke too soon on Codeigniter. It checks a hash of the string with a unique key before running unserialize Peanut and the Gang fucked around with this message at 21:26 on Jun 25, 2010 |
|
#
?
Jun 25, 2010 03:47
|
|
|
Yeah that vuln is cool, I'd be interested to see what's required to bypass Suhosin.
|
|
#
?
Jun 25, 2010 04:58
|
|
|
fletcher posted:Yeah I have always avoided lastInsertId and instead just issue another query to grab the id for whatever was just inserted. Bit of a pain in the rear end, but it works. Darklotus: Be careful with this and make sure you grab the key correctly. If your app is being used by more than one user then it could result in a race condition where you end up with the wrong ID if you just try to fetch the largest value or something like that. What fletcher is most likely doing is running a query for the exact record he just inserted. That could fail though if more than one record is identical, and that depends on what kind of records you are inserting. Some databases have specific functions you can call to get the last inserted id for the current connection. But then you have to change your code to be database specific and then it might get whacky if you are sharing connections. Begby fucked around with this message at 15:28 on Jun 25, 2010 |
|
#
?
Jun 25, 2010 15:25
|
|
|
Thanks, Begby. I'm now using mysql_insert_id() instead of retardedly building a query to find what I just inserted.
|
|
#
?
Jun 25, 2010 17:08
|
|
|
If, in the headers of an email, I specify that it is Content-Type: text/plain; charset=utf-8, then there is no need to escape HTML special characters, correct? (I have functionality where my users can opt to allow other users to send them email messages, mediated by the site. I'm in the middle of rewriting the code.)
|
|
#
?
Jun 25, 2010 19:36
|
|
|
Begby posted:Darklotus: mysql_insert_id() does this safely without grabbing the wrong id. I'm looking for a way to do this with PDO. Any suggestions?
|
|
#
?
Jun 25, 2010 19:55
|
|
|
Hammerite posted:If, in the headers of an email, I specify that it is Content-Type: text/plain; charset=utf-8, then there is no need to escape HTML special characters, correct? (I have functionality where my users can opt to allow other users to send them email messages, mediated by the site. I'm in the middle of rewriting the code.) IE gives no gently caress and will detect and use HTML anyway. Huh, and Safari decided it needed to be downloaded like an octet stream.
|
|
#
?
Jun 25, 2010 20:41
|
|
|
Munkeymon posted:IE gives no gently caress and will detect and use HTML anyway. What HTML, all html? So my users could goatse each other? Send each other malicious scripts? Maybe I should just send minimalist HTML emails, then.
|
|
#
?
Jun 25, 2010 20:57
|
|
|
Hammerite posted:What HTML, all html? So my users could goatse each other? Send each other malicious scripts? Maybe I should just send minimalist HTML emails, then. I don't know where the cutoff is, but if I add the text/plain content header to my normal php whipping boy/testing script, IE still renders it as HTML. To be fair, the first thing in the file is an HTML opening tag, but still, if it's going to ignore your content headers, then you can't just rely on them. That was IE8, by the way, so it's not like it'd just be the users in the IE6 ghetto that'd get goatse'd. There aren't any PEAR classes that will display an email safely? Something in the framework you're using if your using one? edit: messed with it a bit more and it seems inconsistent. If I had an opening pre or img within the first 202 characters, it was HTML, but not an i tag or a b tag. Break tags don't trip it anywhere, so I'm guessing at this point that an opening tag of a tag that has to be closed and is not a single letter somewhere within the first ~200 bytes will trip HTML mode. I'd say be afraid - be very afraid. Munkeymon fucked around with this message at 21:38 on Jun 25, 2010 |
|
#
?
Jun 25, 2010 21:13
|
|
|
Munkeymon posted:I don't know where the cutoff is, but if I add the text/plain content header to my normal php whipping boy/testing script, IE still renders it as HTML. To be fair, the first thing in the file is an HTML opening tag, but still, if it's going to ignore your content headers, then you can't just rely on them. How the email displays is not under my control, only the content is. If a user opts in to receiving emails from other users, then any other user can use a form page to send them an email (they don't see the address).
|
|
#
?
Jun 25, 2010 21:21
|
|
|
Hammerite posted:If, in the headers of an email, I specify that it is Content-Type: text/plain; charset=utf-8, then there is no need to escape HTML special characters, correct? Hammerite posted:How the email displays is not under my control, only the content is. Sounds like you answered your own question there chief.
|
|
#
?
Jun 25, 2010 21:45
|
|
|
DarkLotus posted:mysql_insert_id() does this safely without grabbing the wrong id. I'm looking for a way to do this with PDO. Any suggestions? That is a MySQL specific thing and not all database vendors support it, so there isn't a reliable function to use in PDO for that. http://php.net/manual/en/pdo.lastinsertid.php quote:Note: This method may not return a meaningful or consistent result across different PDO drivers, because the underlying database may not even support the notion of auto-increment fields or sequences. Instead, just issue an extra query to grab the id for what was just inserted: php:<?
$insert = $db->prepare("INSERT INTO user (username, email, password) VALUES (:username, :email, :password)");
$insert->bindParam("username", $username);
$insert->bindParam("email", $email);
$insert->bindParam("password", $password);
if ($insert->execute()) {
$query = $db->prepare("SELECT id FROM user WHERE username = :username AND email = :email AND password = :password");
//etc
}
?>
|
|
#
?
Jun 25, 2010 22:17
|
|
|
epswing posted:Sounds like you answered your own question there chief. What I wanted to find out was whether I could rely on commonly-used software to pay attention to the content-type header and not attempt to detect and display HTML. Which, disregarding for a minute the fact that a lot of software does retarded things, is not an unreasonable thing to imagine might be the case. Turns out I cannot do that though, so I now propose to HTML-escape the user's email and send it as an HTML email. I mean, I'm responding to your post in as much as what you typed actually makes sense. Quoting me saying that I've no control over how content is displayed and making a snarky comment to the effect of "Well then you'd better not send the data in XXX format or it may be willfully misinterpreted in YYY fashion!" really makes only a very facile point (I'd better not send any text that contains the letter "G", either, as it might be viewed using software that replaces the letter "G" with Goatse).
|
|
#
?
Jun 25, 2010 22:49
|
|
|
Hammerite posted:Turns out I cannot do that though, so I now propose to HTML-escape the user's email and send it as an HTML email. The only software that has been mentioned as ignoring Content-type and detecting based on heuristics so far is Internet Explorer. You are sending email. Internet Explorer is not an email program.
|
|
#
?
Jun 25, 2010 23:19
|
|
|
Ok, I guess I'll clarify. You're sending text to an email program, and you can "suggest" but can't control if the content is displayed in plaintext or html, so your options are really simple: if you want to prevent users sending each other html, then escape (or strip) html chars, otherwise don't. I'm not trying to argue with you, I just think you already knew that, and assumed you answered your own question. epswing fucked around with this message at 06:34 on Jun 26, 2010 |
|
#
?
Jun 26, 2010 06:31
|
|
|
I have some dumb memory leak trying to resize a lot of images about 1mb in size each. The script fails through a loop over a directory about half way through when it reaches the server memory limit. Imagedestroy() is supposed to solve this but it apparently isnt. The main function: code:code:I dont get it.
|
|
#
?
Jul 1, 2010 02:23
|
|
|
Definitely doesn't need its own thread but i am sort of assuming PHP programmers have run across the same issue. My youtube video downloader is broken because "get_video" no longer exists, has anybody solved this (quasi-non-php question i know)?
|
|
#
?
Jul 1, 2010 02:26
|
|
|
Sylink posted:
What happens if neither of these are true ?
|
|
#
?
Jul 1, 2010 09:11
|
|
|
JasonV posted:What happens if neither of these are true ? Also, what happens if you have a file name like "png.jpg"?
|
|
#
?
Jul 1, 2010 09:28
|
|
|
Hammerite posted:Also, what happens if you have a file name like "png.jpg"? or something.like.this.jpg surely?
|
|
#
?
Jul 1, 2010 10:58
|
|
|
Would this be a suitable alternative?php:<?
$imginfo = getimagesize($name) or die("Invalid image filename provided");
$imgtype = $imginfo['mime'];
switch ($imgtype) {
case 'image/jpeg':
$src_img=imagecreatefromjpeg($name);
break;
case 'image/png':
$src_img=imagecreatefrompng($name);
break;
default:
die("Image format ".$imgtype." not supported");
}
$old_x = $imginfo[0];
$old_y = $imginfo[1];
?>
|
|
#
?
Jul 1, 2010 11:25
|
|
|
DoctorScurvy posted:Would this be a suitable alternative? Personally I use this (well, the actual version I use is one method of a GD2Image class, but I extracted this bit in isolation): php:<?
// load an image file into gd2, from any given file type
function imagecreatefromfile($path)
{
// want more image loaders? just edit this array...
$image_loaders = array(
IMAGETYPE_JPEG=>'imagecreatefromjpeg',
IMAGETYPE_GIF=>'imagecreatefromgif',
IMAGETYPE_PNG=>'imagecreatefrompng'
);
if(!file_exists($path))
throw new Exception("File Not Found");
$imagetype = exif_imagetype($path);
if(!array_key_exists($imagetype, $image_loaders))
throw new Exception("Unsupported Image Type");
$gd2image = call_user_func($image_loaders[$imagetype], $path);
if($gd2image === FALSE)
throw new Exception("Image Create Error");
return $gd2image;
}
?>the exceptions in this above are bodged, as they are all defined in the class and used all over, I hastily extracted this function, if you see what I mean...
|
|
#
?
Jul 2, 2010 14:40
|
|
|
After several online searches, I couldn't find an answer to this. When I do this: code:code:code:e: fixed it by changing it to get rid of the echo, but an explanation of the 1 would still be appreciated. Master_Odin fucked around with this message at 19:20 on Jul 3, 2010 |
|
#
?
Jul 3, 2010 19:11
|
|
|
Master_Odin posted:e: fixed it by changing it to get rid of the echo, but an explanation of the 1 would still be appreciated. The include succeeded so it returned a 1 which you then echoed.
|
|
#
?
Jul 3, 2010 19:21
|
|
|
I need to write a little php script that will let users upload a CSV file, parse it and then insert records into an sql datbase. The problem I'm having is these CSV files can be pretty big, each line needs some logic to determine what updates and/or inserts need to be run and the whole thing can involve a few thousand queries. The user is left wondering if the script has crashed, I'm stuck upping the max execution time, but any arbitrary limit I set might not be high enough, etc.. I can think of a few ideas how to deal with it, but they seem kind of hackish and was wondering what a good way to do this would be?
|
|
#
?
Jul 9, 2010 17:05
|
|
|
I'd probably just save the uploaded file to a processing directory and have a separate program monitoring for new uploads and running them when they appear. That way the PHP handler for that user's connection isn't the one running the job. You could redirect the user to a status page where the processing program can update them on its progress.
|
|
#
?
Jul 9, 2010 17:23
|
|
|
Sneaking Mission posted:I'd probably just save the uploaded file to a processing directory and have a separate program monitoring for new uploads and running them when they appear. That way the PHP handler for that user's connection isn't the one running the job. You could redirect the user to a status page where the processing program can update them on its progress. Unfortunately, getting that kind of access to the server would involve a lot of red tape and probably get turned down. I'm replacing what is now a manual process which everyone is pretty much happy with, except the poor people who have to spend days doing it by hand...
|
|
#
?
Jul 9, 2010 17:37
|
|
|
|
| # ? Jun 4, 2024 04:36 |
|
|
When it comes to gigantic file uploads, it seems to me that web apps just aren't the right tool for the job. No chance of reimplementing it in something like Java, I suppose?
|
|
#
?
Jul 9, 2010 17:39
|
|
