Jacques1

Gotta love those people who don't manage to write down a simple question and then blame us for not giving them the answers they wanted to hear. Let's summarize: In your first post, you told us that you're seeing failed queries in your error log and that you're scared about “getting hacked”. We gave you the answer to this problem. Now you tell us that you actually generated the errors yourself, that your super-professional application is perfectly secure and that you're just curious how this particular injection technique works. Those are two entirely different stories, and they can't both be true. So what is it? Is the second story now the official version, or will you come up with another one if you don't like what you hear? Time-based Blind SQL injections. It's a standard method of tools like sqlmap to test whether an application is vulnerable to SQL injections. If there's a delay, then obviously the BENCHMARK() call was executed, and that means the code is vulnerable. *lol*

*sigh* Before you try to be smart, please make sure you actually understand the position you're arguing against. Your problem is that you tend to stop reading after the first sentence, immediately construct a bunch of half-baked conclusions in your head and then proudly write down what you think is “the solution”. While this is obviously good enough to impress newbies on a PHP forum, I think a serious programmer should do a bit more than that. Do you realize that I was talking about “common regexes”? Why did I use the word “common”? Was it just an accident? Or could that actually mean something? If you had started PHP a year ago, I'd applaud you all day long for your suggestion. It proves that you know regexes, and that's not bad for the first year. However, I'm pretty sure you've been programming a bit longer, and that means you're expected to actually think about a problem and choose an appropriate solution from several options. This is a parsing problem. Parsing problems usually don't just pop up from nowhere, they belong to a bigger context. That means the OP will most certainly have to make adjustments and solve similar problems in the long run. Can he do that with your regex hack? Hardly: This is cryptic pseudo-Perl bullshit which is optimized for mental masturbation, not readability. Good luck maintaining this and making adjustments, Dareros. This cannot be generalized to anything. It's a throwaway hack for an overspecified problem. If this is your best shot, I'd be worried.

This cannot and should not be done with common regexes. Like you already said, those are complex expression. Your examples are actually still fairly simple. What about this: printf(f(g() + h()), 3 * (2 + i())); This is a full-blown language. Common regexes are way too primitive for this. They work fine for simple tasks like validating a date, but they're no all-powerful parsing tool. What you want is an actual parser. You didn't say which language this is, but I'm pretty sure somebody has already written a parser for it in PHP. Use it.

It's not just the MD5. For some strange reason you've decided to actively change the password by throwing all kinds of functions at it before you store it in the database. Using strip_tags() is particularly harmful, because it deletes everything that resembles HTML markup. If the password happens to include a “<”, then strip_tags() will cut off the password from that point. For example, the strong password “]/q<G,.K9A” would become the incredibly weak password “]/q”. That's obviously a big problem. Do not silently alter the user password! When I choose a password, I want this password, not a shorter password or a different password chosen by you. If you don't know how to protect yourself from SQL injections and cross-site scripting, then ask. But don't just randomly apply all kinds of functions in the hopes that this will somehow make you secure. Programming doesn't work like this. You need to learn about prepared statements as a secure and robust way to pass values from PHP to the database system without fumbling with mysqli_real_escape_string() bcrypt as a modern password hash algorithm how to correctly protect yourself against cross-site scripting; you should erase strip_tags() from your memory

The problem is that you cannot make sure that the code will just set a variable. It's a full-blown script which can do anything. So if any of the dynamic values leaks into the code, you immediately have a cross-site scripting vulnerability or at least a bug. And preventing this is much harder than preventing, say, an SQL injection. Many programmers don't even understand the parsing procedure. For example, in plain HTML, any occurence of the term “</script>” within inline code immediately terminates the current script context and allows the user to create arbitrary HTML elements: <script> var str = "I'm just a harmless string. Or maybe not: </script><script>alert('XSS')</script><script>"; </script> On the other hand, XHTML allows the user to circumvent common escaping mechanism with HTML entities: <?php header('Content-Type: application/xhtml+xml'); ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>XSS</title> </head> <body> <script type="text/javascript"> var str = "I'm just a harmless string. Or maybe not: ";alert('XSS');//"; </script> </body> </html> And those are two of the more harmless examples. Who knows what other ideas people come up with? Trying to safely insert values into a JavaScript context is a battle against weird parsing rules, crazy browsers and very creative individuals. I wouldn't try it. Why not? When the data is needed for the first time, it's retrieved and cached in a global variable. All later function calls can use the cached result.

You see no problem with code where you immediately ran into an unexpected problem, worked on it for more than half an hour and had to look up a feature which you didn't even know before? Well, how do I explain that ... If you ever work in a team or on a project that lives longer than a few months, one of the first things you learn is that fancy solutions are bad solutions. You do not want to keep everybody busy looking up exotic features in the PHP manual or fighting unexpected scope issues like you did. This is a waste of time and a sure way to get bugs. Code should be simple. So if you have the choice between a plain loop (which any PHP programmer can understand in a fraction of a second) and a super-fancy one-liner utilizing the latest PHP features (which people may or may not know), it should be obvious which one you go with. Now, if this is just a hobby project with you being the only programmer, you can of course do whatever you like and use the code primarily to show off your new skills. But for anything else, you want a loop.

Generating dynamic JavaScript code is the worst possible choice and a sure way to get nasty bugs and huge security vulnerabilities. In a properly configured environment, this code wouldn't even run. Appearently you don't have such an environment, so the code does run. But that's no excuse for actually using it. There are exactly two ways to get PHP values into JavaScript: Ajax. This is by far the cleanest, most robust and most secure solution. Use it. I'm not sure why you think you need a separate Ajax request for each click. You don't, just make a single request for all data when the document is loaded. A hidden HTML element which holds the escaped JSON document so that JavaScript can parse the data. This lets you save the one Ajax request, but it's hardly worth the trouble. Don't do this unless you have hard facts which prove that Ajax is not an option.

And you've determined that how exactly? You saw same random-looking strings in the database, you were able to log-in, and now you're happy? Programming doesn't work like that. Just because you're seeing something on the screen doesn't mean that it's all good now. It's not. In fact, getting the output right is usually the easiest part. Any fool can print a bunch of HTML markup. The hard part is what you cannot see: Using functions correctly, making sure that the application is secure, writing good code. And for that matter, you have all the work ahead of you. Of course you're free to ignore all problems and walk away. Some people need to learn the hard way, some people never learn. But if you do want to learn, I can assure you that your code is not OK and that you should take the chance of getting in touch with people who know how to do it correctly.

You cannot prevent people from going back to login.php, because that's simply where they come from. What you can do, however, is redirect them back to main.php if they're already logged in.

I have no idea why you would use a closure when the same thing can be done with a simple loop: <?php $input_table=array('1'=>'toto','2'=>'tota','3'=>'hello','4'=>'TOTO','5'=>'toto'); $look_for = 'Tot'; $found = array(); foreach ($input_table as $word) { if (stripos($word, $look_for) !== false) { $found[] = $word; } } var_dump($found); Or is this not “fancy” enough? I can tell you that when it comes to programming, clarity is much more important than cool-looking code.

It's fascinating to what extend PHP programmers manage to miss the point. I just told you that your whole user management code is so broken that you might as well have no user accounts at all. And what's your concern? Unsetting a bunch of session variables. Yes, that's what's important. When your house is on fire, you first fix the scratch in your fence. And maybe later you take care of that tiny problem with the fire. I have an easy solution: Get rid of this half-assed session stuff and make the site open for everybody. I'm not joking. Pseudo-security is worse than no security, because it deceives the users and makes them think they can safely hand out their data when they can't. This is particularly harmful in the case of passwords, because people commonly reuse them on different sites. So if you're unable or unwilling to provide actual security, get rid of it altogether. Don't make promises you cannot keep. It will save you a lot of time and trouble.

No, you don't. It makes absolutely no sense whatsoever to create an error handler specifically for exceptions. What's so special about them? Should a “normal” fatal error get a different error page, or what? In fact, it's funny that people feverishly catch exceptions and write their own error handlers, but nobody seems to realize that PHP itself already has those functionalities: If a fatal error is triggered, display_errors is off and no output has been generated, PHP automatically emits a 500 response code. Now your webserver simply needs to deliver a custom 500 error page. No code required. There may be some edge cases where the standard error features are not accessible or not sufficient, but most of the time, custom error handlers are completely unnecesary and just repeat core features.

“ful_desc” and “full_desc” are two different identifiers. You need to choose one and stick to it. Besides that, I have no idea why you catch all PDO exceptions and print the message on the screen. Do you really want all users to see your database issues on their screen? Do you realize that the default behaviour of exceptions is much smarter? They send the message to the appropriate device according to your display_errors and your log_errors setting. In a development environment, you'll want the messages on the screen for easier debugging, so you turn display_errors on and log_errors off. On a live site, you want the messages in a log file and not on the screen, so you turn display_errors off and log_errors on.

The first snippet isn't even syntactically valid, so how are we supposed to help you with this? Give us the real code, not some fantasy code you made up. Also note that “__construct” has two underscores. You have only one, which means this is a normal method which doesn't get called anywhere.

We already knew that, thanks.

Even if you did have to include the host (which you don't), what on earth is locahhost'@'root What is “locahhost”? Where are the closing quotes? Why is your format host@user instead of user@host? Please, Moez. At least read your code before you ask others to fix it. And it doesn't hurt to write down a proper error description instead of just dumping the code. Lazy people aren't exactly popular in help forums.

Personally, I would just create the menu ad hoc with a loop. But if you insist on hiding the details behind a single menu entity, you can use a macro. Twig also supports functions, but those serve a very different purpose: They are executed within PHP and allow the template to pull data from the application. This is useful when the data is expensive in some way and at the same time not always needed. It would be a waste of resources to always push the data to the template, so instead you leave it to the template to pull the data when needed. Why do the filenames need to come from the controller? The template should decide which files it needs. Each page template simply adds its own scripts or stylesheets to the head section of the basic template. For example: base.twig <!DOCTYPE HTML> <html> <head> {% block head %} <meta charset="utf-8"> <title>{{ title }}</title> {% block style %} <link rel="stylesheet" href="{{ static_url('style/main.css') }}"> {% endblock %} {% block scripts %}{% endblock %} {% endblock %} </head> <body> {% block body %}{% endblock %} </body> </html> blog.twig {% extends "base.twig" %} {% block style %} {{ parent() }} <link rel="stylesheet" href="{{ static_url('style/blog.css') }}"> {% endblock %} {% block scripts %} {{ parent() }} <script src="{{ static_url('scripts/blog.js') }}"></script> {% endblock %} {% block body %} <h1>My blog</h1> <p>Welcome to my blog!</p> {% endblock %} Note that if you override a block, you can still get the original content with parent() function. So you can put standard stylesheets and scripts into your basic template.

The question doesn't make a lot of sense. As you've already said, the bug was in OpenSSL, not in Apache. Nobody says that you need to use Apache in combination with OpenSSL. For example, there's also mod_gnutls for GnuTLS or mod_nss for the NSS library. If you generally question the security of open-source software, I think this is very naive and a case of security by obscurity. At first sight, it may make sense to keep the code as “secret” as possible so that attackers cannot see it. But in reality, this doesn't work at all. Attackers don't need the source code to find vulnerabilities, and at the same time you lose the benefit of getting feedback from people outside of your team. A lot of “secret” software is broken exactly because it's secret: If only a few people work on a project, and if there's nobody to tell them that they're doing it wrong, that doesn't end well. Good software doesn't come from hiding bugs, it comes from many good programmers working on it. Appearently OpenSSL had some issues with that in the past, but that doesn't mean the concept of open-source software is wrong. To the contrary, we need to embrace it and get a lot more competent programmers to work on OpenSSL. I also find it a bit silly to judge software by a single bug. Sure, “Heartbleed” got a lot of media attention, and now everybody thinks they can bash OpenSSL. But who knows how many bugs are still lurking in other TLS implementations?

Passing some values to a template object on the backend hardly qualifies as “using Twig”, so I do mean the frontend. I create templates with Twig. No. That's also what I do. However, the great thing about Twig is that there isn't really a “right” and a “wrong” way. You can choose from different techniques according to your personal preferences. For example, you don't have to use inheritance. You might as well make a template for the head section and insert that into each page template. You shouldn't have any HTML markup in your PHP code. I mean, preventing this kind of spaghetti code is pretty much the whole point of template engines. The template should create the output, PHP only does the logic and provides the data. Think of the output as a completely separate aspect: Who says it's always HTML? Maybe one day you want a PDF document instead. Or an entirely different format. There's no reason why that shouldn't be possible given that the data isn't tied to HTML in any way.

Are you sure that the code in your first post is actually the one you're using? Are you sure that you're generating the anti-CSRF token only in the form script? And does the problem always occur or only sometimes, maybe after you've switched the browser tab? In any case, regenerating the token on every request is a bad idea in the times of tabbed browsing. The problem you currently have is exactly what will happen to your users if they open your forms in multiple tabs: Once they submit a form, the token in the session changes, and the tokens of all other tabs are out of sync and must be manually refreshed. Otherwise the user gets a token mismatch. This is very annoying and has very little benefit for security. In fact, I have a hard time coming up with a scenario where it would even make sense to refresh the token more often than the session ID. Generate the token once when the session is created and keep it until the end of the session. This may in fact fix your problem immediately.

I do use Twig and occasionally Smarty.

Then I have no idea why you told us that it's impossible to make “Ajax requests” with cURL. Was it just a brainfart?

Being afraid that the template engine might suddenly die doesn't make a lot of sense. Smarty has been around for 13 years, which is a lot given that PHP itself is less than 20 years old. It's also constantly updated and improved, and there's absolutely no reason to believe that this will change in the future. Twig is “only” 5 years old, but it's maintained by one of the most active and knowledgeable community in the PHP universe. This is not an amateur project like CodeIgniter. But even if a template engine somehow dies, you can use a transcompiler to convert the templates into a different language. My company has actually done that just recently. We converted all templates of a big online shop from Smarty to Twig, and we had no issues whatsoever. We just had to do a few manual corrections for some edge cases. I'm actually surprised that template engines are still such a hot topic in the PHP community. And I'm baffled how many people insist on using the incredibly fugly, verbose and primitive PHP syntax. It's almost masochistic. You've hard-coded the “UTF-8” setting into your function, but there are many other encodings you might encounter. This is not just a theoretical problem: If you or somebody else reuses the class for a different project which does not use UTF-8, the mismatch can in fact break the escaping mechanism entirely. The encoding should be set by the user. For example, you could make a (mandatory) parameter in the constructor: class View { protected $encoding; public function __construct($encoding) { $this->encoding = $encoding; } // ... public function escape($data) { return htmlspecialchars($data, ENT_QUOTES, $this->encoding); } } If, for some strange reason, you insist on restricting the class to UTF-8-encoded templates, use a class constant and write a big warning into the script and the documentation: class View { const ENCODING = 'UTF-8'; // ... public function escape($data) { return htmlspecialchars($data, ENT_QUOTES, self::ENCODING); } }

No offense, jazzman, but I think you're very confused. The communication between the client and the server consists of exchanging IP packets (which contain the HTTP messages). The server doesn't know anything about the client except the IP address. It has absolutely no idea what the client did to generate the data: Could be Ajax, could be a “classical” request, could be cURL or any other tool. Hell, the client could have manually typed in the bytes with their keyboard. We don't know, and we cannot find out. All we know is that a particular IP address has sent us an HTTP request. For the server, there's no such thing as “Ajax”. This is a client-side technique, and you have no way to detect or enforce it. Think of the client as a black box: Data goes in, data goes out, but what happens inside the box is completely unknown. Is it a human user or a bot? Do they use a browser? If they use a browser, do they have JavaScript enabled? We have no idea.

An Ajax request is an HTTP request. Have you never opened the “network” tab of your browser to see what's going on behind the scenes? It doesn't matter if the request comes from JavaScript or cURL or whatever. You might as well write it down by hand. The server doesn't know and doesn't care. It's all just a bunch of bytes in a bunch of IP packets.