masterlayouts

Hello Larry, Thank you for all your help, I learned many things reading your books and now I am back to the desk for learning after many hours of producing. You were right that a programmer may have a very nice life doing procedural programming and I have to say that I finished a quite big project and I didn't mind 'repeating myself' as in fact was not that bad, put things in functions and the repeating part was rather easy: copy/paste and changing a few things. I like the fact that I can keep things separate, HTML, SQL, PHP, CSS. Anyway... I've got so used with your way and the patterns I learned from book that now I have a question related OOP. Is it a mistake if I use the same structure, for example the "configuration" file and the "connection" file and simply rewrite in oop syntax? Especially the database connection file that usually in frameworks does not stay outside the "http" folder. if I do write, let's say, a validation class for forms and for some project this is all that I need, is it a mistake that I do not create a CRUD class and other things like a framework has? I know it sounds like reinventing the wheel, but it is not quite like that. An existing framework has a lot of things that are useless to small projects and require maintenance that small projects do not necessary need. Why should I have the forms, for example, generated from PHP when, maybe, as part as my workflow, I prefer have them in HTML, so I can see them and work visually, like in Dreamweaver. I guess many with a background in design and not in programming would prefer it this way. Let's take for example Dreamweaver, it has some basic things that can do "programming for poets" and it is really fast, but it lacks a server side validation script. A simple validation class to resolve this issue will resolve a lot of problems and speed up the development. Will this be a bad thing ("unprofessional")? I look at your "Shopping Cart Widget" class in the book. You do not actually create a very general class and extend it afterwards in a framework style. It performs pretty particular things and probably can be abstracted more (a guess). Is that example just for study (as it compares with the procedural code before) or it may really be a production piece of code? If you add, let's say, real time quotes from Fedex, is it necessary to write a class "ShippingClass" than extend it with "ShippingFedexClass" when, assuming it is possible, writting just a functio in your Shopping Cart Widget class may provide shipping quotes? Bottom line, if we do not have very abstractizied classes for everything and keep things separate (things like forms, I believe this is a very good example), is this a mistake? Is it possible to have the best of both worlds? Thank you, Greg

Does it make any sense, security wise, to have the front-end separated by back-end of an application by storing the two sets of data in different databases? Or there are other ways how to separate one from the other, as per example by setting different privileges for users who access the database? Thank you.

Because we plan for it and this is the client's specifications. It is a job site, so there will be many pages with job listings, split by various criteria like country, domain...etc. Here it make sense the approach learned from your book example. People apply for jobs. The number of people that apply for a certain job it's a lot smaller... we should have less than 2-3 pages with results (as opposed to hundreds and maybe thousands). Here I was thinking to make the pagination based on the number returned by mysqli_stmt_num_rows($stmt). Both are generated on the fly, but it is a safe assumption that we have a small set of results returned for certain type of pages/queries. Thank you for your answer.

Thank you for your reply, I put it together and works well. I do not want to beat the death horse, but I have another question related to the issue of pagination. In the script provided we check first for a parameter p for the page, and if it's not provided we query to find out how many records do we have and split the records per page. Certainly, when we anticipate a lot of records and we do not expect (or there are not so important) changes I can certainly see the advantage of querying first for a count of the records than limit the query. Now I am thinking to two situations. First situation, when the changes operated are important (like deleting one of the records), which would require a recount. Second, when we expect the number of returned records to be small. In these situations, wouldn't be easier or even faster than instead of using two queries, one to do the count the second to retrieve the records, to use just the second query to retrieve the records and use something like $totalRecords = mysqli_stmt_num_rows($stmt); to get the number of records retrieved and operate the pagination based on this value. I understand that this way we have to retrieve all the results every time, which is a more expensive query in case of many records than the quick count and the second limited by LIMIT to the number entered in $display. But for the circumstances mentioned when changes are important and we do not expect a very large number of returned records, will be a mistake to make the pagination this way?

Thank you for your answer. I have a search page and a result page. I changed the form method from POST to GET as per your advise. If the form has a text field named "keywords" and the value empty, also a submit button named "search" with the value "search database" when I click on the submit button I noticed a few things and I would like to ask a few questions about it. First I noticed that the URL contain a parameter 'submit' and its value, like following: http://localhost/results.php?keywords=&search=search+database My first question is if it's possible to eliminate the submit button from the URL (and generally if it's possible to eliminate any form element from being passed in the URL)? Than I noticed the spaces are replaced by "+". When we take the value with $_GET the "+" returns to empty space. Now if I use "+" in the keyword (like "+TV -Samsung") as in a boolean search, the "+" get encoded, where "-" and all the other characters (like double quotes) doesn't. If I search for the expression: +"widescreen tv" -Samsung the result is: http://localhost/results.php?keywords=%2B%22widescreen+tv%22+-Samsung&search=search+database I assume that I have to get the keywords value with $_GET['keywords'] and run it through mysqli_real_escape_string() and this is the search result page. Is this the proper way of doing a search-result page? I am asking because initially I was thinking to apply what I learned in the beginning of the book and use POST to handle the form, than redirect to the results page with the parameters appended to the URL and values URL encoded. I assume this is the wrong way of doing it.

I have the following problem. On the page where I output the results of the query I also have the form (it is the same page). One of the fields is used by users for keyword searches in boolean mode (MATCH... AGAINST). Now if I click the link to the next set of results p=2&s=10 (let's say) I get an error because the content of the form is empty and even if I gave the parameters for "page" and "start" I do not pass the input for user's search/keywords (that input text field). I was thinking to put the input into a hidden field and the value of that hidden field will always be the $_POST for the keywords field. I am not sure this is the best approach, but I guess it is better than encoding the user input and passing it in the url. Maybe I am wrong. Could you please let me know what you think? Also wouldn't be better if we calculate the $start page based on the $page and $display (so we don't have to pass it as parameter in URL)? On a separate note I noticed that using prepared statements there are a few methods that I guess may be used for paginating results, like "mysqli_stmt_store_result" and "mysqli_stmt_data_seek". Is it possible / better to re-write the script using these? I also noticed that there are another methods for multi-query and I was thinking that they may be used very nicely on a pagination script because of the "mysqli_stmt_more_results" and "mysqli_stmt_next_result" which seems to fit perfect for the task. I would appreciate your help. This is probably one good example of beautiful things that may be achieved with prepared questions and cannot be obtained otherwise (multi-query). <suggestion> on the next edition of your book, please extend the prepared statements chapter or please write a book about it. Thank you.

True, but the root of the problem is the same thing that we debate in other thread: properly sanitizing the user input. If the input is properly sanitized I do not see how anybody would benefit of a function that search for the presence of keywords such "CC" and "BCC". With the same token we should create functions that are hunting keywords to prevent SQL injection, yet we do not do that. We prefer as mechanism of defense sanitizing the user data. I would prefer not to use a function such the scrubber, but to have a high degree of certainty that the user input is properly sanitized. I expressed myself wrong, clearly there is no "body" isolated by "header", you are right to point it out. bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

I am sorry, this being a written forum and not a speaking one you must took it the wrong way. Obviously I cannot pretend to you to be clairvoyant and anticipate changes in mysql engines. In fact you received similar questions about PHP6 and my opinion was (as you can probably check) that it cause no difficulties of understanding and learning PHP. I merely made a suggestion that the forum as well as the book should reflect major changes and I believe the new innodb with fullindex feature is such a major change. My point was not to through away the book, but to pin a thread, add a downloadable pdf annex to keep readers updated. I do not think is such a terrible idea and I do believe that people will continue the trend to drop myisam engine for innodb. One of the links posted is from owasp. They believe the first mechanism of defense against SQL injection is prepared statements. I would simply wanted to see more code in your book using prepared statements, this is what I understand by "more secure". Not that your code is unsecure, but if all reputable security sources are saying the same thing: use prepared statements, I guess a reason should be. Hence "more secure" code. You were right, the tread started with the question posted in title: "Does Form Input That Goes In A Match Query Need To Be Sanitized?". Your answer was that all user input should be sanitized. But admittedly there are degrees here as well. If I do not use the output of the query why would I sanitize the input of the parameter that goes in MATCH... AGAINST? Advising me to sanitize all input do not carry too much weight, I would certainly expect a more detailed answer. My suggestion was to look at what goes to the database and what we output from the database as separate problems. I do not know if it is a good thought or not, I am not saying, I am asking. I was expected a debate, not a fight. In any case, just for the sake of the argument, your redirect that you are using mysqli and not mysql (true), does not resolve the issue. mysqli_real_escape_string() does the same thing as mysql_real_escape_string(). What I said it fails to do is true for both of them: What I think failing to sanitize the backtick does is to create the risk of sql injection and it was rated as critical by owasp, not by me. I guess you understand better than me the examples offered. I can think to a simple fix, but maybe there are other solutions better than the one suggested. I guess all the examples offered in the links provided are replicable. I for one I checked if the backtick is escaped or not by the mysqli_real_escape_string function and it wasn't. Maybe I do not understand the depth of the problem, but it sure is a problem and I was hoping for your explanation and solution to the problem. I always mention that I am a beginner. When I put something down I am eagerly waiting for your answer, sometimes I know it is something wrong, but I do not understand or not understand entirely why it is wrong, so I ask to find out. Otherwise I know what I am asking is simple, but I am asking to be sure. Rest assured that I was in no way disrespectful, it was not my intention. You can take a look at the ranking and review I gave your books. But I will be more careful in the future posts and create my own tag <suggestion>, <point of debate> and so on for not to be confused with other things as blame, disrespect, bad opinion...etc. If I am wrong everywhere else, you are wrong at least here: I do not think you are a bad teacher. au contraire.

if the user input is properly sanitized from the beginning i do not see how the form may be abused. The problem is why would somebody have access to the email's header in the first place? Why would somebody be allowed to enter control characters as input in the form? If it's a contact form, than the first argument of the function mail is hidden, the second should take the subject and I will let it alphanumeric, than the body. I see no point in hunting CC and BCC... $string = "\n \r"; echo filter_var($string, FILTER_SANITIZE_SPECIAL_CHARS);

Thank you for your answer. I guess we have one kind of problems with input and another kind of problems with the output. I just gave an XSS example, but the question was meant for SQL injection as well. I am happy you address them both and made the distinction clear. In my opinion, the first kind of problems does not necessary cause problems to the other and vice-versa. One can have a XSS problem if decide to output the result query and in that result figures the attacker's crafted XSS snippet, otherwise there is no problem. In this context I was asking about the queries that perform searches based on keywords of the type that occurs in fulltext, aka MATCH... AGAINST. I see no reason to disallow a search for an input that contains tags as far as I do not output the problematic input. In this sense, I guess, the form input does not have to be sanitized against XSS, but only against SQL injection. Coming back to the injection issue I am pretty sure you know that this is not enough to prevent SQL injection. For example, the backtick it's not sanitized by this function. As result, all applications that use only the kind of protection you suggest are vulnerable. To the best of my (limited) knowledge all form input should be reduced at minimum acceptable, like alphanumeric for most of the fields. For everything else that exceeds alphanumeric input, regular expressions are preferable catered precisely for that thing. For fields like address where no discernible pattern is possible I would pretty much stay with alphanumeric. For search queries, I believe the input field should be sanitized only against SQL injection and never used the output directly on the page. For quick and general use on small projects I guess the advise would be mysql_real_escape_string() + a regular expression that will search and eliminate all problematic characters such backtick (at least). In my opinion, we should learn about mysql mode and programming without prepared statements only from an historic point of view. in fact PHP depreciated the mysql mode and suggest only mysqli and pdo. Bottom line here is the mysql_real_escape_string() fail to sanitize the input in such a way that the injection to be prevented. After small research I find out that MySQL object names are not protected by encode_sql and this is the root of the problem. Also I find out it may be fixed at the server level in that particular file. There are a few interesting links I like to share: http://stackoverflow...5811853#5811853 https://www.owasp.or...ion_Cheat_Sheet https://makandracard...names-for-mysql I hope this is useful. I am just surprised that a huge security hole such the failure of mysql_real_escape_string() to properly sanitize backtick was not mentioned in your book (or forum). It should be as unless prepared statements or stored procedure are used, everything else is vulnerable and the severity of the problem is critical. At the end of the day it's an easy fix: eliminate backtick's from user's input. But how many are actually doing it? Overall, from the time you wrote the book I guess there are several thing that changed, such as everything you said about myisam and innodb engines. Now innodb engine supports fulltext indexing, so pretty much nobody will use myisam. Than everything else that lacks prepared statements should be just an historic perspective. It would be more interesting to be taught to write secure code from beginning. When it comes to mysql_real_escape_string() function it must be said always that it is not enough and at very list the input should be sanitized against backtick.

All form input has to be sanitized and run through mysqli_real_escape mechanism. My question is do we have to sanitize the form input for that/those field/fields that will add to a query whose function is just search and that input is never displayed or otherwise used in the application? As result risky user input as the attempt of XSS or SQL injection may happen. I am interested to know if the database will take care of the input and escape it or do whatever it is necessary by itself or do I have to sanitize the input before add it to the query? $q = 'SELECT subject, body FROM messages WHERE MATCH(body, subject) AGAINST($_POST['unsanitizedUserInput'])'; user enter: <IMG SRC="javascript:alert('XSS');"> Where user may enter anything at all, in my example I put for brevity an XSS attempt, that obviously cannot do anything wrong here, but it is not my example that I want to discuss but the concept behind it. I cannot think to any input that may cause problems, but some other people may do. Sorry for the syntax errors, I hope I am made myself clear even if the example chosen is wrong. It is a good question as in the book the examples for fulltext index are very basic and do not discuss security issues at all. In all the other parts of the book you discuss them, as in the case of mysql statements where you said to run everything through mysql_real_escape() for example. I would like to know if in case of search we do have to run the input that goes only on search through such a function or not and in general what advise you can gave us security wise about FULLTEXT searches and user input. In this example the query do not cause security problems, but maybe there are situations when it may cause security problems. Question remains: do we sanitize the user input that goes in searches or not? Thank you. $q = 'SELECT subject, body FROM messages WHERE MATCH(body, subject) AGAINST(\'<IMG SRC="javascript:alert(\'XSS\');">\')';

Should we sanitize it or the db will handle it? $q = 'SELECT subject, body FROM messages WHERE MATCH(body, subject) AGAINST('<IMG SRC="javascript:alert('XSS');">')'; Can you please put it in an working example?

Hi Hartley, thank you for your reply. The thing is that the number of values is variable and doing something to generate a unique name requires the same effort. I am interested in the best practices here, otherwise I assume it may be done either way. I am also interested if having the value of the parameter of numeric value is an advantage or not. I am guessing it is easier to use numbers; on the other hand if the database has a look up table to restrict the input to predefined values and this values are string I assume it is equally safe, the advantage being that it has meaning and one don't have to do any extra effort to interpret what the numeric value means. Now I do not have enough experience to decide.

http://www.larryullm...__fromsearch__1 I am using PHP 5.3 and I never encountered any problem with the examples in this book. Before I was using PHP 5.2 and still didn't run into any problem. From what you say you are using you should not have any issues at all.

Sending values to a script (chapter 9), we are using hidden form fields and URL parameters. What if I want to pass more values for one parameter? (not "name1=value1&name2=value2", rather "name1" having "value1" and "value2"). In the hidden form element I guess we define the element's value as an array. I am more interested in the URL situation, what will work best. Is it safer to use numeric values as parameters or strings will be just fine?