requinix

There are a number of false positives in there... Pay attention to the ones involving glob().

SimpleXML $xml = new SimpleXMLElement($string, 0, false); echo (string)$xml->Transaction->Description;

REAL uses floating-point which means it cannot always give exact values. Use DECIMAL if you need exact values.

Off the top of my head, both GIFs and JPEGs allow for arbitrary comments. It is entirely possible for images to contain malicious code. [edit] Besides, getimagesize() only inspects a very small amount of the image. Just enough to grab the information it needs. It does not validate images.

Thanks for the description but that wasn't what I was asking for.

GD doesn't know what "nefarious code" is. It was a "I believe" that it will not keep unrecognized stuff. For most people I would say "easier" but you won't really know until you try.

Nicest option is to redirect to some page immediately after the operation. Thus refresh only refreshes that page. Otherwise you can include nonce tokens: unique values that are only good for one use. Record that token somewhere, like the session, and only allow the operation if the token hasn't been used.

- Without going through the source code, I believe GD will write the image from scratch, because otherwise it would have to remember all the little bits of fluff it encounters when loading the data - and then write them back, assuming that the fluff is still accurate even after modifying the image. (Saying this because I know specifically of a few things that depend on the image data, thus changing the image data screws them up.) - JPEGs are best for photographs. If people upload a PNG then it's quite possible they're not uploading a photograph (eg, some icon or glyph), in which case you probably want to keep it as a PNG. Then there's GIFs which can be animated. So it'll probably be better to keep whatever format they use. - GD is quick and simple but isn't that great at preserving quality during operations (especially with palette images). If you need to keep quality, try ImageMagick instead.

Look into KML. Much easier.

What it sounds like you're asking, no. The referrer is the only piece of history the browser sends (if it even does) and it's only the previous page (supposedly).

Such as index.php?location=index.php And boom goes the dynamite.

Substituting that whole segment? You can just find the "/ref=" and grab everything else after it - don't need any "numbers, letters, and underscores" logic. #/ref=.*#

Do any of the values have a dollar sign? Like $25.00? Or the generic question: what are the exact values of those two variables?

Which looks like...?

Who wrote the original code?

You're not checking the password at all... Also, 1. Use POST. 2. Hash the password in your JavaScript before sending it in the URL and/or use SSL.

Does it still do that if you use a different browser?

Depends on the server...

You did? I don't see how.

The easiest change would be to use the /e flag. Causes preg_replace() to evaluate the replacement string (after substitutions) as PHP code rather than a literal string.

To be pedantic, you should also addslashes() for JavaScript string issues and htmlentities() for HTML issues. htmlentities(addslashes(urlencode($quizTitle)))

1. Forms always have methods. It is not possible for them to not have one. If you don't specify one then it is GET by default. 2. Make your process.php check that the form('s fields) were submitted using whatever method it wants. For a login form you must use POST - otherwise, with GET, the credentials will show up in the URL and that's Bad. if (empty($_POST["userName"]) || empty($_POST["pass"])) { // form was not submitted properly // do something, like redirect or show a login form with error or whatever } else { // form was submitted properly }

A couple more answers since the question is a bit ambiguous: - if that URL is in a string then use parse_url - the whole query string (without the question mark) is in $_SERVER["QUERY_STRING"]

That's true, but why should any of us go out of our way to do the work for you? We'd love to help you do it, though, if you're willing to put some time into it.

In terms of SQL injection, no there isn't anything you need to do once something in the database. There's still XSS injection to think about though. Verify the data is what you expect it to be before inserting it into the database, and use htmlentities() when echoing it out into your HTML. "Usually" isn't enough.