Jacques1

Why don't you read the friggin' replies? What's the point of asking a question, ignoring the replies and coming back with the same question a month later? All that does is waste everybodys' time (yours included) and piss off the people trying to help you.

Do yourself a favor and stop using the Dreamweaver code generator. It's awful, and you'll never learn PHP from it. The mysql_* functions are also obsolete since more than 10 years and will be removed in one of the next PHP releases. Nowawadys, we use PDO. So instead of spending your time debugging shitty auto-generated code, why don't you learn the language and write your own code? After almost 5 years, it's about time.

The original code is wide open to session fixation attacks, because it happily adopts any user-provided ID. An attacker doesn't even have to steal the ID. They can make up their own (or get a fresh ID from you), trick the victim's browser into using it and wait for the victim to log-in. After this, they have a fully authenticated session. That's what needs to be fixed first. The problem is that the PHP session API doesn't distinguish between starting a new session and resuming an existing session. When you call session_start(), you get any of the following: a new session with a new ID a new session with an old ID provided by the user an old session When you authenticate a user, you certainly do not want to reuse an old ID or even run into an an existing session. You want a fresh session with a new ID. The current workaround for this is to reset the ID with session_regenerate_id() while making sure that no old content is carried over to the new session: <?php /* * Starting a new session. * * We can't just use session_start(), because it may do any of the following: * - start a new session with a new ID * - start a new session with a user-provided ID (which enables session fixation attacks) * - resume an existing session */ session_start(); // PHP may have resumed an existing session. Make sure we don't carry over any data to the new session. $_SESSION = array(); // Reset the session ID to make sure we don't reuse a known ID. The argument tells PHP to delete the old session. session_regenerate_id(true); // *Now* we have a new session. Write the data to $_SESSION as usual. Session hijacking is indeed a problem, but most advice on how to protect against it is incredibly naive, including the Shifflet article above. There are two ways how an attacker might obtain the session ID of another user: by listening to the network traffic by exploiting security holes on your site, in particular cross-site scripting vulnerabilities To protect against network attacks, use HTTPS at all times and set the Secure flag of the session cookie (this means it will only transmitted over HTTPS). Way too many sites still run around with plain HTTP, making it easy for an attacker to steal all kinds of data. In the second case, session hijacking is really your least problem. In fact, if an attacker has found a cross-site scripting vulnerability, they don't need the session ID. They can do (almost) anything they want with the account simply by controlling the victim's browser through JavaScript code. So it's naive to assume that the attacker is primarly interested in getting the ID so that they can then log-in as that user. Why should they? An automated attack from the victim's browser itself is much more efficient. The only case where they can't do that is if the session is valid for multiple domains and they want to read data from a different domain. This isn't possible with JavaScript due to the same-origin policy, so the attacker will indeed try to get the session ID. This can be prevented by setting the HTTPOnly flag of the session cookie (which means the cookie can't be read by JavaScript). This user agent stuff does not help. An attacker who has managed to obtain the session ID of a victim gets the user agent for free. And even if they don't know the UA, they'll simply try out all possiblities. There aren't too many. Wrapping it up: Fix your session initialization. Use HTTPS at all times and set the Secure flag of the session cookie. Set the HTTPOnly flag as well. Double-check that you don't have any cross-site scripting vulnerabilities in your code. In addition to that, you should remove all inline scripts and use Content Security Policy.

Did you not read the replies? Two people just told you that you cannot do this. What you should do is fix the concept of your competition so that it works on the Internet. Your current concept is obviously designed for an offline environment.

Like I said, you render the pages dynamically. It might be a good idea to start with a smaller project so that you get used to the idea of dynamic websites.

Sorry, Leverkusen, but this is nonsense. And I think a web developer should understand the web well enough to realize this. The “proxy detection” you have in mind doesn't work, locks out legitimate users and is simply nonsense. If your competition doesn't work on the Internet, then that's the problem. There's obviously an issue with the concept.

Why would you think that? You have an object. This object has a method which creates an instance of another class and returns the instance. What's so surpring about that? That's what object-oriented programming is all about.

Because the PDOStatement instance is returned by the query() method. Check your code: You call query(), put the return value into the $query variable and then call $query->fetch(). So $query is obviously an object. If you inspect the variable, you'll see that it's indeed an instance of PDOStatement. The rest of the code doesn't make a lot of sense, though. What's the weird try statement supposed to do? Do you realize that exceptions by default halt the script and send the error message to the appropriate device? What's the point of catching the exception only to manually halt the script and print the error message? Also, do you really think it's a good idea to show your internal database errors on the website? In general: Don't catch an exception unless you actually know how to handle it. PDO needs to be configured. At the very least, you should turn on prepared statements and specify the character encoding. Otherwise, you'll easily end up with security vulnerabilities or broken characters respectively. It's also a good idea to define the default fetch mode. This while loop stuff is no longer needed. You can simply use a foreach loop. Using PDO properly might look something like this: <?php $database = new PDO('mysql:host=YOURHOST;dbname=YOURDB;charset=utf8mb4', 'YOURUSER', 'YOURPASSWORD', array( // we want actual prepared statements, not client-side escaping PDO::ATTR_EMULATE_PREPARES => false, // turn on exceptions PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // fetch associative arrays by default PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, )); // a constant query $blogEntriesStmt = $database->query(' SELECT blog_entry_id, content FROM blog_entries '); foreach ($blogEntriesStmt as $blogEntry) { echo '<p>' . htmlEscape($blogEntry['content']) . '</p>'; } // a prepared statement $category = 1; $categoryEntriesStmt = $database->prepare(' SELECT blog_entry_id, content FROM blog_entries WHERE category = :category '); $categoryEntriesStmt->execute(array( 'category' => $category, )); foreach ($categoryEntriesStmt as $blogEntry) { echo '<p>' . htmlEscape($blogEntry['content']) . '</p>'; }

I think you're missing the whole point of web programming languages like PHP. The reason why we use PHP is because we do not want tons of static files for different pages. We render the HTML dynamically. So if your content is in a database, you fetch the data, assemble the page and display it.

Please don't do this. Turning on allow_url_fopen means that PHP no longer distinguishes between local files which reside on your server and remote files which reside somewhere on the Internet. Depending on your PHP version and settings, PHP will even run remote files on your server if asked for it. Anybody with a little bit of fantasy should be able to imagine why this is an incredibly bad idea. Or just read the Wikipedia article on Remote File Inclusion vulnerabilities. From all security risks you're facing as a web developer, I'd say this is pretty much the worst one. Well, the PHP developers obviously didn't find this insecure enough, so as a bonus, they turned off SSL certificate verification by default. In other words, PHP will send the sensitive data to anybody who asks for it. So just don't do it. Use cURL. It's the de-facto standard for making HTTP requests from an application and was written by people who actually know a bit about security.

Sorry, but changing the method to POST makes absolutely no sense. The reason why you see parameters in the URL is because pressing the button submits the form. If you change the method, you're still submitting the form. The only difference is that now the parameters are sent via the message body rather than the URL. But they're still there. Even worse, now the browser will issue a warning whenever you try to reload the page, because it needs to know whether it should resend the data. So, no, this is not the answer. If you don't want to submit data, well, why have a form in the first place? Delete it, and the problem will go away.

Managing the cache headers is the job of your webserver. So you should grab the documentation of nginx or Apache or whatever it is you're using and look up how to do it.

None of this makes a lot of sense. The first INSERT query isn't valid SQL syntax. I'm not even sure what you're trying to do there. Did you mix up the syntax of UPDATE and INSERT? Did you want to use the special INSERT INTO ... SET ... syntax provided by MySQL? The query is wide open to SQL injections. You're randomly applying three different escaping functions to some of the values, but you don't seem to understand what they do and when to use them. You're applying or die(mysql_error()) to a string? Do you really want the whole world to see your database errors? The mysql_* functions are obsolete since more than 10 years, they're deprecated since PHP 5.5, and they will be removed in one of the next PHP versions. It's about time to switch. The center element is obsolete since HTML 4. That was back in 1997! A redirect with JavaScript? Why not an actual HTTP redirect with the header() function? This date() thing is odd. I think what you actually want is date('d F Y').

Have you read any of the replies? Several people have told you multiple times that your strange data format makes no sense, but you just keep going. What's the matter?

My question is why you want to tunnel the grand total through a form instead of calculating it when needed. It makes no sense to let the user tell you the value. What if they're lying?

Why do you want to submit the grand total at all? Why not calculate it on the checkout page? And I hope the value is purely informational? Because obviously you cannot trust the user input.

See this thread for a detailed explanation why it's a bad idea to run user input through intval() or any other string-to-integer converter. The very first reason (value truncation) already applies to you: Your life_event_id is an UNSIGNED INT, which means the IDs can range from 0 to 232 − 1. However, if you run the application in a 32-bit PHP, then a PHP integer can only cover the first half from 0 to 231 − 1. Any ID above that cannot be represented and is silently reduced to 231 − 1. That's obviously a problem. The solution is to not mangle the user input. Don't run it through intval(), abs() or whatever. Just use a prepared statement to pass the values to the database system in a secure manner. There also seems to be a lot of confusion regarding is_int(), is_numeric() etc. As mac_gyver already explained, you cannot use is_numeric(), because it simply doesn't do what you want. This is for any number (not just integers) in all kinds of “strange” formats. You can't use is_int() either, because this literally checks if the value is a PHP integer. Of course it's not, it's a string. What you want is ctype_digit(). This checks if the string only contains decimal digits, which is exactly how the decimal representation of a non-negative integer looks like. To wrap it up: validation with ctype_digit() security through a prepared statement

If most of the files are images, try getimagesize(). You can also combine this with the finfo_file() and extension checks (for the files which have one).

Your script runs before the element exists. You need $(document).ready().

How your HTML form looks like is completely irrelevant for the communication between the client and the server. Anybody can send any data to you. It's important to understand that the client and the server are actually just exchanging HTTP messages. All the browsers and HTML documents and fancy GUIs are only there to make the WWW human-friendly. We don't need them. I could open my console right now, create an arbitrary HTTP message and send it to your server. If you then blindly accept the data based on the assumption that I've used your form, that's a problem. Any client-side restrictions you may have set up are purely advisory. It's simply a way of telling the user which kind of data you expect from them. The actual data you get may be completely different. So, yes, you have to escape all input, be it a POST parameter, a cookie, an HTTP header or whatever. Even better: escape every value and don't make any assumptions about whether or not a certain value is dangerous. It's too easy to get this wrong. For example, many people still believe that $_SERVER['PHP_SELF'] is just a harmless filepath which couldn't possibly cause any harm. Well, this is wrong. And even if a value is indeed not dangerous, it can still contain critical characters and cause a syntax error.

No offense, but it might be a good idea to leave this task to somebody else. Sessions are highly sensitive, because they're used for authentication and access control. If you don't know what you're doing and screw this up, you can get everybody into serious trouble.

The manual knows.

This syntax is supposed to be used in templates, not in code. PHP used to be a template engine for embedding short sections of code within HTML markup. That's why there are PHP tags, and that's why the alternative syntax exists: <h1>My blog</h1> <ul> <?php foreach ($blog_posts as $blog_post): ?> <li> <h2><?= html_escape($blog_post['title']) ?></h2> <p><?= html_escape($blog_post['text']) ?></p> </li> <?php endforeach; ?> </ul> You can't really use the usual brace syntax here, because it would be difficult to tell which brace terminates which statement. Now that PHP has become a full-blown programming language, people tend to embed their HTML markup in the code instead of the other way round, and the alternative syntax is rarely used. That's actually a pity, because it would help fighting the spaghetti code problem.

Yes, you can display all kinds of information in all kinds of ways. But before you worry about such details, I'd first take care of getting the upload itself right.

And what are you doing after this? You obviously have yet another htmlentities() or htmlspecialchars() call somewhere which destroys the tags. If you just output $message, you will very well get bold text.