php|architect (April 2004)

VOLUME III - ISSUE 4 APRIL 2004 The Magazine For PHP Professionals & Internationalization! Multi-lingual websites ma...

48 downloads 1431 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Username:

Email:

You can already make a very educated guess about the type of SQL statement that this application will construct. It will most likely be an INSERT statement that uses $_POST[‘reg_username’] and $_POST[‘reg_email’]. You can also make a guess about the naming convention used in the database, because it possibly matches the names used in the HTML form. Because this form is for registration, there is also likely to be a password generated and included in the query. From all of this, you guess that the following construction is performed: $sql = “INSERT INTO users ( reg_username,

April 2004

●

PHP Architect

●

www.phparch.com

reg_password, reg_email) VALUES (‘{$_POST[‘reg_username’]}’, ‘$reg_password’, ‘{$_POST[‘reg_email’]}’)”;

Assuming this guess is correct, what can you do to manipulate this query? Imagine sending the following username: bad_guy’, ‘mypass’, ‘’), (‘good_guy

If [email protected] is given for reg_email, and the password generated by the application is 12345, then the SQL statement becomes the following: INSERT INTO users (reg_username, reg_password, reg_email) VALUES (‘bad_guy’, ‘mypass’, ‘’), (‘good_guy’,‘12345’, ‘[email protected]’)

This statement creates two accounts: good_guy with a valid email address and bad_guy with no email address. Because reg_email is valid, if the application emails the password for the good_guy account, it will arrive safely. You already know the password for the bad_guy account, because you set it yourself. Thus, by sending a specially crafted username, you have created two accounts that you can perhaps use for further malicious activity. You can use the good_guy account to investigate the application and learn how it works (a valid account might be required to access cer-

55

SECURITY CORNER tain parts). With the bad_guy account (which is also a valid account), you can launch additional attacks with your heightened privilege without the risk of losing your real account if something goes wrong (the bad_guy account is disposable). More importantly, if this is successful (no error is given by the application, and you can log in as bad_guy), it sufficiently proves that there is very poor data filtering, if any at all. You may be wanting more examples of SQL injection attacks, so I will demonstrate another style. Keep in mind that creativity plays a large role, as is the case for most styles of attack. In the example just explained, the attack is limited by the type of query (IINSERT) and the placement of the client data. Other types of queries present new opportunities, and the best practices mentioned in this article prevent practically all SQL injection attacks. WHERE Hacking The WHERE clause is used to restrict the records that a particular query matches. For a SELECT statement, it determines the records that are returned. For an UPDATE statement, it determines the records that are altered. For a DELETE statement, it determines the records that are deleted. If a user can manipulate the WHERE clause, there are a lot of opportunities to make drastic changes—selecting, updating, and deleting arbitrary records in the database. Imagine a SELECT statement intended to fetch all credit card numbers for the current user: $sql = “SELECT card_num, card_name, card_expiry FROM credit_cards WHERE username = ‘{$_GET[‘username’]}’”;

In this particular case, the application might not even be soliciting the username, but rather providing it in a link: View Credit Card(s) for Your Account

Because a user can have multiple cards, the application loops through the results, displaying the card number, the name on the card, and the card’s expiration date for each one. Imagine a user who visits the following URL: /account.php?username=shiflett%27+OR+username+%3D+%27 lerdorf

This submits the following value for the username: shiflett’ OR username = ‘lerdorf

If used in the previous SQL statement, the following is the result: SELECT card_num, card_name, card_expiry FROM credit_cards

April 2004

●

PHP Architect

●

www.phparch.com

WHERE username = ‘shiflett’ OR username = ‘lerdorf’

Now the user sees a list of all credit cards belonging to either shiflett or lerdorf. This is a pretty major security vulnerability. Of course, a larger vulnerability exists in this particular example, because a user can arbitrarily pass any username on the URL. In addition, a username that causes the WHERE clause to match all records can be used: shiflett’ or username = username

Imagine if this particular username were actually stored in the database (using a previous SQL injection attack) and used as the attacker’s username by the application. Everywhere that a WHERE clause is used to restrict a query to the user’s own record can actually include additional records (or all records). This is not only extremely dangerous, but it also makes further attacks very convenient. Data Filtering Note: The methods to be described assume that magic_quotes is disabled. If magic_quotes is enabled, you can use the fix_magic_quotes() function that is listed at: http://phundamentals.nyphp.org/storingretrieving

There are best practices that you should follow to prevent SQL injection attacks, and these offer a very high level of protection. The most important step is to filter all data that comes from the client. This includes $_GET, $_POST, $_COOKIE, and $_FILES. To help clarify this, consider the following HTML form: red green blue

Clearly, the expected values are red, green, and blue. So, the data filtering should verify this: $clean = array(); $valid_colors = array(‘red’, ‘green’, ‘blue’); if (!in_array($_POST[‘color’], $valid_colors)) { /* Display error */ } else { $clean[‘color’] = $_POST[‘color’]; }

This code uses a separate array ($$clean) to store the filtered data. It is a good idea to choose a naming convention that will help you identify potentially tainted data. In this example, $clean[‘color’] - if it exists - can be trusted to contain a valid color, because it is first ini-

56

SECURITY CORNER tialized and then only set to $_POST[‘color’] if it passes the validation. Another option for a set of expected values is to use a switch statement: $clean = array(); switch ($_POST[‘color’]) { case ‘red’: case ‘green’: case ‘blue’: $clean[‘color’] = $_POST[‘color’]; break; default: /* Display error */ break; }

For numeric data, the is_numeric() function is a good choice. Filtering other types of data can be more difficult, but regular expressions can be very helpful. For example, my favorite validation logic for an email address is as follows: $email = ‘[email protected]’; $clean = array(); $email_pattern = ‘/^[^@\s]+@([-a-z0-9]+\.)+[az]{2,}$/i’; if (!preg_match($email_pattern, $email)) { /* Display error */ } else { $clean[‘email’] = $email; }

The two most important points for data filtering are: 1. Only accept valid data rather than trying to prevent invalid data. 2. Choose a naming convention that helps you distinguish tainted data from filtered data.

Escaping Data With properly filtered data, you’re already pretty well protected against malicious attacks. The only remaining step is to escape it such that the format of the data doesn’t accidentally interfere with the format of the SQL statement. If you are using MySQL, this simply requires you to pass all user input through mysql_escape_string() prior to use: $clean[‘color’] = mysql_escape_string($clean[‘color’]); $sql = “... {$clean[‘color’]} ...”;

In this case, assuming $clean[‘color’] comes from the previous example, we can be sure that the data only contains alphabetic characters. However, it is a good habit to always escape data. This practice will help you avoid forgetting this crucial step. Until Next Time... Preventing SQL injection is easy, but it is one of the most common PHP application vulnerabilities. Hopefully you will now always perform the following two steps: 1. Filter data from the client 2. Escape data used in SQL Of course, you should always filter client data, so the only new step is to escape data before you use it in an SQL statement. If you use MySQL, this only requires a function call to mysql_escape_string(). There is a helpful resource located at phundamentals.nyphp.org/storingretrieving that explains this second step in much more detail (focus on the section regarding data storage). I hope that you are now protected against SQL injection attacks and can prevent such vulnerabilities in your applications. Until next month, be safe.

Figure 1

About the Author

?>

Chris Shiflett is a frequent contributor to the PHP community and one of the leading security experts in the field. His solutions to security problems are often used as points of reference, and these solutions are showcased in his talks at conferences such as ApacheCon and the O'Reilly Open Source Convention, his answers to questions on mailing lists such as PHP-General and NYPHP-Talk, and his articles in publications such as PHP Magazine and php|architect. Security Corner, his new monthly column for php|architect, is the industry's first and foremost PHP security column. Chris is the author of the HTTP Developer's Handbook (Sams Publishing) and is currently writing PHP Security (O'Reilly and Associates). In order to help bolster the strength of the PHP community, he is also leading an effort to create a PHP community site at PHPCommunity.org. You can contact him at [email protected] or visit his Web site at http://shiflett.org/.

April 2004

●

PHP Architect

●

www.phparch.com

57

T I P S

&

T R I C K S

Tips & Tricks By John W. Holmes

Eleven Tips to a Successful Technical Presentation This month’s column is going to be a little different from what I’ve done in the past. I know this will be published well after php|cruise will have taken place, but this tip is in regard to something I, personally, got out of the cruise (one of many things, actually). Giving a presentation can be difficult. Some people have a natural knack for it and can make any topic interesting and keep the audience involved, and more importantly, awake. For the rest of us, though, talking in front of a crowd can be a really painful experience. Giving a technical presentation, such as something about PHP features, can be even more difficult, as you now have more pieces to work with. You have to worry about how and where to show your code and working examples of it, how you are going to talk and type at the same time, etc. So, I just wanted to give a few presentation tips to those of you (hopefully) preparing to speak at the next PHP conference. php|cruise #2 to Alaska will be here before you know it—and you can never start to prepare too early. Lastly, this certainly isn’t a jab at any php|cruise presenters, since I’m sure you’re out there reading this. Everyone enjoyed all of the presentations on the cruise, but it never hurts to go over things like this again. 1) Rehearse: This is a must. You have to run through your presentation a couple times and preferably in front of other people so they can provide feedback. Some people are really good at impromptu speaking and can April 2004

●

PHP Architect

●

www.phparch.com

wing it, but it still doesn’t hurt to run through it just to see how long it takes. You want to ensure you’re speaking at a moderate pass and not talking to fast. You don’t want to run out of material half way through your presentation time. Running over your time limit can be just as bad, also. When you run over, it delays everything after you. If you’re the one planning a conference, you can’t necessarily plan for extra time between presentations, either. If you think you may run over on time, let the planner know. Maybe you can go last so you don’t mess anyone else up? 2) Dry Run: This is basically the last rehearsal, but the key is that it should be done where you’re actually going to give the presentation. Yes, I know this isn’t always possible, but you should try to make it happen. If you didn’t bring your own equipment, this will give you chance to ensure that what you have will work on the equipment provided. Obviously, it’s better to identify problems as soon as possible. What looks good on your CRT monitor doesn’t always look good from a projector (or whatever display system they have). Do you have all of the cables you need to show your presentation? Do the colors show up (especially yellows and oranges). Can you read the fonts from the front and back of the room? Do you need a microphone? If you have a quiet voice, then one may be required even though you may be in a small conference area. 3) Typing Code: You have to be very careful any time

59

TIPS & TRICKS you find yourself typing during a presentation. Your eyes are now on the keyboard or screen instead of the audience. You’re making the audience wait on you as you show them how to do something that they already know how to do. You’re bound to make errors as you type, also, which results in even more time spent typing and not concentrating on the audience. If you need to show code during your presentation, either work it into your presentation slides, or have it already typed and just load the files into a text editor when it’s time to show them. The flow of your presentation will not be interrupted except for the time it takes for the file to load.

“R

you after the presentation or ask when there is more time. Trying to “hold all questions” until the end isn’t really going to work, either, especially if the audience is small. It’s better to go over the questions while the pertinent slide is being displayed rather than having to flip back and forth to find the relevant slide. Also, by learning what’s interesting to confusing to the audience through their questions can allow you to adapt your topics and maybe speed up or slow down for certain topics. 7) Time: Time is your enemy, well, one of them, at least. This is why you rehearse and try to stay on schedule, even with questions. If you realize that you have more info to present than planned, keep in touch with whomever is planning the conference and try to request more time. You may or may not get it. Maybe you can be moved to last in the daily schedule, so that, if you run over, you’re not affecting pre-

unning over your time 4) Text Editors: If you’re going to use one, make sure you can adjust limit can be just as bad, the text size. What looks good and also. When you run over, it easy to read on your monitor may delays everything not look that way during the actual presentation. Also, take note of after you. “ how long your lines and entire scripts are. Scrolling left and right or many pages down can be a pain during the middle of a presentation. If possible, have senters after you. your code already opened in an editor and learn or Here again is where an assistant comes in handy, as make shortcuts to get back and forth between it and they can keep an eye on the clock and attempt to keep your presentation. This way your audience is not wait- you on schedule. ing on you. 8) Graphics and Transitions: I’m going to back-peddle 5) Have an Assistant: This kind of goes along with all on my stance for this one a little bit. I was originally of the above suggestions; try to have an assistant that going to say that I didn’t see a need for pretty graphics can help you give your presentation. I realize this isn’t and transitions if they didn’t actually pertain to the always possible, but there can be a lot of benefits if you topic. However, after seeing a few examples of how make this happen. The simplest benefit is that you can random graphics or transitions can keep the audience have your assistant flipping slides and scrolling at the interested and awaiting the next slides, I can see where right times without you having to say “next slide” or they will be useful. Hopefully, you’ll be an interesting anything else. This keeps your eyes and attention on enough of a speaker or have an interesting enough of the audience instead of the computer. a topic to keep the audience’s attention. If not, howevIf you really need to type (see tip 3 and 4 again), like er, I guess it can’t hurt to throw in the random picture filling out a form during a live demo, then have your of your kid or cat. assistant do it. You can continue explaining concepts or The only thing to keep in mind is that the additional what the results of the changes are going to be while graphics are going to increase the size of the file overyour assistant types. all. This may be an issue if you make your slides availYou can even make your assistant the bad guy that able for download. Consider having a graphic-free verkeeps you on track and on time and cuts off questions sion available for download that people on low-speed when necessary, but that’s up to you. connections can acquire. This leads us right into the next tip. 6) Questions: Speaking of questions, try to pause between each slide and at least look up to see if anyone 9) Make Slides Available: This one should be a nohas any questions. Too many people get their nose brainer, but make sure people can get to your slides caught-up in the computer or looking at their slides after the presentation, especially if they contain code. that they miss people who want to ask a question. Another thing to realize, also, is that not everyone runs Realize that a large amount of questions may push you whatever program you are running to make and disover your time limit, also. Don’t be afraid to cut ques- play your slides. You should make an attempt to make tions off when your time is up or when you really need them available in a basic format like HTML or PDF. to get to your next slide. If it’s important, they’ll find Remember that, at this point, you’re just putting the April 2004

●

PHP Architect

●

www.phparch.com

60

TIPS & TRICKS info out there, you’re not presenting it. It doesn’t have to look the same—just show the information so people can read it. If you’re the one organizing a conference, try to have everything available at one location so people don’t have to look around for it. Put an easy to remember link in your presentation that people can write down quickly, if possible. 10) Uhmmmm: Try to avoid excessive “uhmms” and “ahhs” and other noise words when you’re in front of an audience. Sometimes this is really hard for people, especially if you’re nervous, so rehearsing and experience is going to help. You may not even realize you’re doing this until you do a rehearsal in front of someone. 11) Font Size: This tip is added for Chris Shiflett, who pointed it out a couple of times to me: make your font size huge. This includes your slides, obviously, but also text editors, command lines, browsers, etc. Do this before your conference, also. You may not plan on opening up a text editor or command line, but the questions from the audience may force you to. Be prepared and adjust the font sizes beforehand. These tips certainly aren’t all inclusive and are mostly

April 2004

●

PHP Architect

●

www.phparch.com

from the perspective of an audience member. Feel free to join the Tips & Tricks forum at http://www.phparch.com/discuss to add your own recommendations or offer comments about these eleven suggestions. This isn’t a wholly original topic, either, as many other people have discussed what it takes to give a good presentation. Chris pointed out a link to me for a great presentation by M. J. Dominus on “Conference Presentation Judo” at: http://perl.plover.com/yak/presentation/

The presentation shows how you can balance content, humor and graphics in order to give an awesome presentation. The included notes give even more suggestions about how to cover each slide the “correct way” and should be required reading. Enjoy the show.

php|a

61

The Place to be for PHP Professionals! ter s i g e R Now ! m a ny Te a p m Co unt! Disco

Amsterdam May 3 to 5, 2004

www.phpconference.com Main Conference: May 4-5, 2004 Power Workshops: May 3, 2004

International PHP Conference 2004

Spring Edition Organizer:

Want to Share? Come to Canada!

e x i t ( 0 ) ;

By Marco Tabini

F

or all their geographical proximity, Canada and the United States are, and remain, two very different countries. Ask most Canadians, and they’ll tell you that, although they consider Americans their brothers, they’re happy to have their own place to call home— and proud of their societal customs and traditions. Ask most Americans—or, for that matter, most people outside Canada— and they’ll likely tell you that Canada is that perennially cold place up there where it snows all the time and people go around on dog sleighs and end all their sentences with “eh?”. I will have you know, my dear readers, that nothing could be farther from the truth. We only use dog sleighs for no more than three or four months out of every year (at least from what I can tell when I get on the highway in the morning here in Toronto) and, as I write this col-

April 2004

●

PHP Architect

●

www.phparch.com

umn (on April 5th, 2004—there, so much for not dating your material) there is barely a foot of snow on the ground, a bright sun shines outside and we’re well above ten degrees below zero, eh?

“In Canada, however, there is no DMCA (Digital Millennium Copyright Act), and our privacy laws are extremely strong.”

But I digress—let me go back to the real reason why I am here. As you probably know—given that you follow this column religiously from month to month— a few issues back I reported that the Recording Industry

Association of America (which we’ll refer to as RIAA from now on, least we run out of paper over the next three sentences) sued several hundred people in the US for sharing music files over the Internet. Here in Canada, the RIAA’s cousin, called the Canadian Recording Industry Association, or CRIA for those of us who like to save trees, took the first steps to do the same to a couple dozen Canadians last month, and was run through the shredder by a federal judge. The CRIA was not actually suing anybody for sharing digital music; they were seeking to force several large ISPs—among them the biggest in Canada—to give up personal information about people who, according to them, had illegally shared music over the Internet. Justice Konrad von Finckenstein, who, despite his name, is a thoroughly Canadian figure, ruled against the request, stating in his find-

63

EXIT(0);

Want to Share? Come to Canada!

ings that the CRIA did not present even one shred of evidence that could be considered usable in a court of law. Justice von Finckenstein must have been on a roll, because he hardly stopped there, ruling that sharing files per se does not violate Canadian copyright laws. A computer that is sharing files is, in his view, akin to a photocopier left at a public library—the library itself is not responsible for people violating copyright laws by photocopying other people’s work. On the surface, this is very good news for the file sharers. Personally, and for what it’s worth, I think that Justice von Finckenstein rendered an excellent ruling that finally sets the recording industry, with all the arrogance that American copyright laws have afforded it, back in its place. The methodologies that the RIAA and CRIA have used to identify file sharers is deeply flawed and has produced more than one false positives in the past. Naturally, the RIAA doesn’t care, because it has the money to pursue as many lawsuits as it sees fit, and to bully the average Joe into any kind of settlement it wants. Being on the receiving end of a lawsuit is a nasty business—the kind of business that costs a lot of money just to defend yourself, regardless of whether you’re completely innocent or guilty as charged (although those terms are normally applied to criminal cases and file-sharing is normally a matter for the civil courts). As a result, a certain number of fail-safe measures have to be built into the system. Otherwise, a party with bottomless pockets will punctually overcome a

April 2004

●

PHP Architect

●

www.phparch.com

weaker party by the simple exercise of what lawyers refer to as “papering to death”, and what I refer to as “ruining your weekends” (it is, apparently, a longstanding practice that any legal paperwork must be served on an opposing party on a Friday afternoon, just so that you can ruin their weekends). If these fail-safe measures were not in place, “justice for all” would become “justice for the highest bidder”.

“The methodologies that the RIAA and CRIA have used to identify file sharers is deeply flawed and has produced more than one false positives in the past.” To be sure, the judicial system is—even in the eyes of this layman—not perfect. A financially stronger party has the upper hand in that it can always force you into litigation, no matter how ridiculously frivolous their claim is, and “bleed” you out of whatever money you have before any useful conclusion can be reached in a court of law by simply forcing your lawyer to spend time considering frivolous matters. In the case of the RIAA, the American government has, under the guise of the Digital Millennium Copyright Act (DMCA), relaxed some of the fail-safe measures designed to protect the privacy of individuals in favour of the copyright holders’ right to protect their work. In Canada, however, there is no DMCA, and our privacy laws are extremely strong. This, cou-

pled with what seems to have been lack of good, old-fashioned research and several strategic faux-pas on the CRIA’s part, have resulted in the recent ruling. As much as I am grateful for Justice von Finckenstein’s ruling, I have my reservations. My worry is that people will take it as a free pass to file sharing— which is not, in my opinion, what it means. As I have said, file sharing is wrong, but, on a large enough scale, it is also a form of expression for people who want to protest the music industry’s market strategies. The RIAA/CRIA have tried to quash that form of expression by brute force—simply because it is less expensive to do so than to give up their business model of selling you a CD for more than tape cassette, where the latter actually costs less to manufacture. We are, after all, talking about the same industry group that gets a levy from each blank CD-R and cassette tape sold here in Canada as “compensation” against intellectual property piracy—regardless of whether you use that CD-R to store your personal document, family photo album or—God forbid—a backup copy of some software program you own. On the other hand, by opening the issue up so dramatically, Justice von Finckenstein’s ruling may finally force the CRIA to look at the problem from a different angle and start implementing fair business practices. Sadly, they are now working on their appeal... so we’ll have to put that thought on hold for a little while longer. php|a

64

Spektrum der Wissenschaft April 2004 issue 04

Microsoft Architects Journal: Journal 2 (April, 2004)

April

April

April

April

April)

April

April

April)

April

April (April Shadows)

Global Financial Stability Report: Market Developments And Issues April 2004

Moving And Accessing Sas 9.1 Files April 2004

2004)

2004

2004

tempestuous april

Second April

April Lady

April Shadows

April Love

April 1988)

April Fool

April Lady

April Lady

April Lady

April Lady

Cold April

April North

php|architect (April 2004)

Spektrum der Wissenschaft April 2004 issue 04

Microsoft Architects Journal: Journal 2 (April, 2004)

April

April

April

April

April)

April

April

April)

April

April (April Shadows)

Global Financial Stability Report: Market Developments And Issues April 2004

Moving And Accessing Sas 9.1 Files April 2004

2004)

2004

2004

tempestuous april

Second April

April Lady

April Shadows

April Love

April 1988)

April Fool

April Lady

April Lady

April Lady

April Lady

Cold April

April North

Recommend Documents