Jump to content

Christian F.

Staff Alumni
 View Profile  See their activity

  • Posts

    3,072

  • Joined

  • Last visited

  • Days Won

    18

 Content Type 

Everything posted by Christian F.

  1. Christian F.
    Oh, snap! Didn't see that he'd put it inside the loop. Better go get me some brain fuel, I think. Sorry about the mixup.
  2. Christian F.
    Do you get any errors when running the code? Does something else that you don't expect happen, or does anything at all happen? In other words: We need more information from you about the nature of the problems, or concerns, you're having in order to help you. The more information you give us, the easier it'll be for us to actually help you.
  3. Christian F.
    That's not PHP. Either that, or you're missing a whole lot of code we need to see.
  4. Christian F.
    Nope, it won't. for ($run = 0; $run < 10; $run++) { $arr['test'][] = array ($run); } var_dump ($arr); /* Result: array(1) { ["test"]=> array(10) { [0]=> array(1) { [0]=> int(0) } [1]=> array(1) { [0]=> int(1) } [2]=> array(1) { [0]=> int(2) } [3]=> array(1) { [0]=> int(3) } [4]=> array(1) { [0]=> int(4) } [5]=> array(1) { [0]=> int(5) } [6]=> array(1) { [0]=> int(6) } [7]=> array(1) { [0]=> int(7) } [8]=> array(1) { [0]=> int( } [9]=> array(1) { [0]=> int(9) } } } */ That said, it is a very good practise to do so anyway. Cuts down on the number of warnings, and avoids potential problems.
  5. Christian F.
    "preg_replace ()" will automatically replace all occurrences of the pattern, just like what you're looking for. (Replaced my original post, as I were mixing languages. PHP has no "g" modifier...)
  6. Christian F.
    Yes, thus my comment. Try with the original string, then you'll see what I mean.
  7. Christian F.
    Here's what I got when I tried to visit the URL manually: URL: http://pinnacleeducationservices.com/send_contact_info.php Method: GET Status: 302 Found Request GET /send_contact_info.php HTTP/1.1 User-Agent: Opera/9.80 (X11; Linux x86_64; U; en-GB) Presto/2.10.289 Version/12.00 Host: pinnacleeducationservices.com Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: en-GB,en;q=0.9,nb;q=0.8,no;q=0.7 Accept-Encoding: gzip, deflate Connection: Keep-Alive Response HTTP/1.1 302 Found Date: Sat, 28 Jul 2012 22:47:16 GMT Server: Apache Location: http://verygoods-2014.ru/in.cgi?11&ur=1&HTTP_REFERER=statistic.com Content-Length: 337 Keep-Alive: timeout=10, max=30 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://verygoods-2014.ru/in.cgi?11&ur=1&HTTP_REFERER=statistic.com">here</a>.</p> <hr> <address>Apache Server at pinnacleeducationservices.com Port 80</address> </body></html> I suspect an .htaccess (or something similar) lying hidden in that folder, or a parent folder. Either targeting that file in particular, or php files in general. Might even be that your web server have been compromised, mind you.
  8. Christian F.
    Make that sub group capturing, and we agree.
  9. Christian F.
    Seems we both missed out on something: Though, I should indeed have thought about the possibility of the search term being the first word in the string. I shall fix that right away. Addendum: Hmm.... Seems I can't go back and edit my post any more. Oh, well. Here's the updated version: $string = "@Christian is testing!"; $replace = '$1<a href="" class="profile_name" id="$2">$2</a>'; echo preg_replace ("/((?<!\\S))@(\\S+)/u", $replace, $string);
  10. Christian F.
    Ah, you got a point there. Forgot about them. Sorry about that. Thanks for reminding/correcting me.
  11. Christian F.
    Yep, that's exactly what it says. With the added bit of storing that "everything that isn't a space" in a sub group, which is then referenced to by the "$1" in the replacement string. RegExp sure is great, but easily abused and can get really complex really fast. So take heed when using it.
  12. Christian F.
    Yeah, noticed it right after posting. Changed it while you were posting.
  13. Christian F.
    Tarential: No need to bind the RegExp to the start and end of the string. We're not talking about validating the entire string, but just looking to grab a little subset of it. Shadowing: To sum up this little thread, what you'll need is something that looks like this: $string = "hey what's up @sam how are you doing?"; $replace = ' <a href="" class="profile_name" id="$1">$1</a>'; echo preg_replace ("/\\s@(\\S+)/u", $replace, $string); Double escaping since "\" is a meta-character in PHP strings. "\\S" is the same as "[^\\s]+", only with less typing. Also using the "u" modifier to make it UTF-8 compatible. Also, added a space in front of the anchor-tag, to replace the one we're removing in the RegExp.
  14. Christian F.
    Just to ensure that there are no confusion: This has nothing to do with PDO per se, but is true for all Prepared Statements. MySQLi also supports PS, so it's just as safe to use MySQLi with PS as PDO with PS. The only thing PDO brings to the table, so to say, is a standardized set of functions to access the DB. So that you don't have to go ":s/mysqli/psql/g" (or similar) should you want to change database engines. However, chances are you'll still need to massage the queries themselves a bit in that case. Depending upon their complexity, and similarity of the DBMS' SQL dialects, of course.
  15. Christian F.
    Damnit.... Wrote a really long post, detailing all of the issues I found in your code, just to lose it in an accidental page refresh. In short: You have some massive security holes in that code, due to complete lack of input validation and output escaping. The use of "intval ()" and the PHP input filters will help with the first, and for the latter you should read up on "htmlspecialchars ()" and "mysql_real_escape_string ()". "stripslashes ()" is completely unnecessary in your script, and a prime example of an anti-pattern. Completely unneeded while loop at line 20, as well as freeing of results and closing the database connection. The biggest indication that you might have some issues with the basic syntax however, is this: $_SESSION[iD] = ".$_POST."; Where there are no less than 3 issues: Abuse of "ID" as constant, which will cause problems if it ever gets defined. Always use quotes around string values, which you have done on the second page. $_POST is an array, the code above will result in $_SESSION['ID'] containing ".Array." It seems you've fallen victim to an anti-pattern, and misunderstood how to use it on top of that. Some developers, who doesn't really know what they're doing, tend to concatenate string (or numerical) values with empty strings. What they think that's necessary I do not know, but it's a complete waste. (Like opening, closing, opening, walking through, closing, opening and then closing the door, every time you walk through one.) The correct way to write that line, would have been as follows. Using the data you retrieved from the DB, and thus know to be correct & safe. $_SESSION['ID'] = $Event_info['ID']; Good points: Good work on the indenting and commenting, as well as parsing all PHP code before sending any HTML to the browser. As for those who said that "session_start ()" needs to be at the very top of the file: No, it doesn't. It is sufficient that no content has been sent to the browser, to allow for the extra headers to be added to the HTTP response. This is fulfilled in this case.
  16. Christian F.
    You're thinking a bit too complicated about this, try to reduce the task into simple steps and it should be a lot easier to see what you need to do. A little example of what I mean, this is what you're looking to do: Sig creator: - If form not submitted. - Show form & quit - If no files uploaded or error. - Show error - Repopulate form data. - Show form & quit. - Validate files & other input - If not validated. - Show error. - Repopulate form data. - Show form & quit. - Handle upload of files. - Merge pictures & text. Makes it a whole lot easier to see what you need to do, doesn't it?
  17. Christian F.
    I recommend that you start with the Twitter API documentation.
  18. Christian F.
    Remember to generate a new salt as well, for that little bit of added security.
  19. Christian F.
    I see that people are confusing their terms a bit. Session lifetime is not the same as cookie lifetime, even the session cookie. The browser can (and frequently does) delete the session cookie without the server deleting the session, or vice versa (though a lot more uncommon). What normally happens is that the server creates a new session, stores it on the disk and sends a cookie with a corresponding ID to the client. When the client is then closed, the cookie gets deleted from the "jar". However, the server does not know anything about this, and as such keeps the session alive and stored on disk. It's not until the session.gc_maxlifetime has been reached that the server will mark it for deletion. Before that time, however, it's entirely possible to manually craft the session cookie and resume the session. So, the questions are: Are we talking about the session cookie lifetime, auto-login features, or the actual maximum life time of the server-session? If the latter: Are you talking about how long the session will last after the last change, or since the user logged on IOW, forced logoff after a while)? If it's the session cookie lifetime, or auto-login features, then you've already gotten your answer. If it's the session maximum lifetime, then the situation becomes a bit more complicated. Usually, however, you're good to just leave it at default. Unless you encounter problems, or have any other specific (normally security-related) reasons for needing to change it.
  20. Christian F.
    I'm really interested in the reason why you don't want to run an UPDATE query on the database? That is the real question, at least in my mind. Depending upon your reasoning for this decision the answer you got is either the correct one, or this whole thread is a red herring. Which is why I'm wondering.
  21. Christian F.
    I'd do it slightly differently, in that I'd do the validation for the form on the current step. Instead of doing the validation on the next step. That'll keep all the relevant code on the same "page" (file or function), and make it a bit easier to maintain. In short my steps would be like this: Step #: - If not submit - Print form & quit - If input not validated - Repopulate form with user-data - Print form & quit - Save input - Increase step counter - Redirect to next step (GET).
  22. Christian F.
    As nine7ySix already have pointed out, you will have problems with the above code due to the liberally distributed PHP-tags. Not because of the tags themselves, but because of the whitespace in between. This gets sent to the browser, which in turns causes the web server to send out all headers. If you take a look at the PHP manual you'll quickly see why that's a Bad Thing. Secondly, why are you running the same query twice in a row? $q_user = mysql_query("SELECT * FROM customer WHERE username='$name'"); /* SNIP */ if(mysql_num_rows($q_user) == 1) { $query = mysql_query("SELECT * FROM customer WHERE username='$name'"); This is a complete waste of time and resources, as you have the results available already in the $q_user variable. The third point I'd like to mention is that you seem to store your password in clear text, which is a very Bad Thing. Always(!) hash your passwords, with individual salts. That is, hash not encrypt?/url]. For my fourth point I'd like to reiterate what nine7ySix already said: Always escape output when sending it to a different parser/system. That means "htmlspecialchars ()" for (non-HTML) output to browsers, "rawurlencode ()" for URLs, "mysql_real_escape_string ()" or Prepared Statements for MySQL and so forth. Combined with proper input validation this will drastically reduce the number of weak spots in your application, might even remove them completely depending upon the complexity of your code. And lastly, something I don't think a lot of people are aware over: $_SERVER['REMOTE_ADDR'] can be spoofed. That means that it is quite trivial for an attack to add whatever s/he likes to the URL request, and make it appear as if it's your server that's attacking your GeoIP provider instead. That's why you always validate input from the user, and never trust client-provided data. (Granted, in this case it might be difficult to actually know that we're talking about client-provided data.) PS: I know this thread is a little old, but seeing as most of my comments are security related, and might be of use for someone else, I decided to reply anyone.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.