PHP Web Application Security

PHP is one of the most widely-used web programming languages in the world. In this course, you'll learn to write more secure PHP code.
Course info
Rating
(27)
Level
Intermediate
Updated
Sep 1, 2016
Duration
5h 18m
Table of contents
Course Overview
PHP Web Application Security
Input Validation
Cross-site Scripting (XSS)
SQL Injection
State Management
Cross-site Request Forgery (CSRF)
Storing Passwords
Error Handling
Conclusion
Description
Course info
Rating
(27)
Level
Intermediate
Updated
Sep 1, 2016
Duration
5h 18m
Description

Web applications are under attack every day. PHP, being one of the most widely-used programming languages on the web, is one of the main targets. Some oddities, especially those of older versions, facilitate some of the attacks. This course, PHP Web Application Security, helps developers to understand security risks, how vulnerabilities can be exploited, and how to avoid those attacks. First you'll learn about how to defend against cross-site scripting, including new approaches such as content security policy. Next, you'll learn about how cross-site request forgery works, why it works so well, and how you can implement protection using PHP. Finally, the course will wrap up by teaching you how to protect against SQL injection attacks, covering not only MySQL, but also other relevant databases PHP supports. By the end of this course, you'll have the knowledge to anticipate and defend against the major threats against web applications today.

About the author
About the author

Christian Wenz is an author, consultant and trainer focusing on web technologies. He wrote or co-wrote over 100 books, is a fixture at international developer conferences since 2001, is a Microsoft Most Valuable Professional (MVP) for ASP.NET, an ASPInsiders member, and main author of the Zend PHP 5.5 certification.

More from the author
Building a Site with Angular and PHP
Intermediate
3h 51m
20 Dec 2017
What's New in PHP 7
Intermediate
1h 45m
3 Dec 2015
More courses by Christian Wenz
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi everyone. My name is Christian Wenz, and welcome to my course PHP Web Application Security. I'm a partner at Arrabiata Solutions, and support several companies in everything web including web performance and web application security. About 15 years ago, I discovered the topic web application security for myself thinking that I work on that for a year or two. Well, I'm still here and according to a study, 9 out of 10 web applications do have security issues. Recent high profile incidents prove that the topic is still around today and more important than ever. In this course, we're going to learn how our PHP web applications may become number 10 out of 10 avoiding as many security issues as possible. We discuss attacks, counter measures, and what PHP brings to the table. Some of the major topics that we will cover include defending against cross-site scripting including new approaches, such as content security policy, how cross-site request forgery works, why it works so well, and how to implement protection using PHP, protecting against SQL injection attacks covering not only my SQL, but also other relevant databases PHP supports, and several more attacks and what to do against them. By the end of this course, you'll know how to anticipate and defend against the major threats for web applications today. Before beginning the course, you should be familiar with PHP in general. You might consider the PHP Get Started course as a good basis. I hope you'll join me on this journey with the PHP Web Application Security course at Pluralsight.

Input Validation
This module is all about Input Validation. Remember, the two rules from the previous module, validate input and escape output. Here, we talk about input and validating it. First, we discuss what is input for a web application and how can we access input from PHP and then we see which extensions, functions, approaches, techniques PHP provides us with to validate input. Not every attack can be mitigated by just validating input because some input might be harmless in a certain context, but also be very dangerous in another context and that will be a topic for the further modules. But so far, there is some kind of input that we can validate and here you'll see how it's done. If you don't do it, eventually, things will go very, very wrong, so let's get started.

Cross-site Scripting (XSS)
Let's talk about Cross-Site Scripting, or XSS in short. Yes, I know CSS would be the more logical choice for an abbreviation, but as you also know, CSS is already taken by something else, so XSS, cross-site scripting. The name is pretty self-explanatory. It's scripting so it must have something to do with JavaScript code that comes from somewhere else cross-site. Usually, that means that the attacker somehow injects the JavaScript code or makes your browser execute the JavaScript code. We will talk about the attack, why it works, what it can do, and of course, what we can do against cross-site scripting.

SQL Injection
So I was watching the latest installment in the Jason Bourne movie series the other day and in one scene that took place somewhere in Iceland, a stereo typical group of hackers were well doing their work and one said to the other, user SQL to corrupt their databases. I guess the audience was pretty technical because half of the room emerged in laughter, and well yes, the wording is kind of funny, no one would use that, but they have a true point. SQL may be used to in some way harm a database, well actually that's kind of what SQL is made for, updating a database, deleting from a database, stuff like that. However, when we have a web application, usually only the server is supposed to talk to the database. If the server, however, accepts input from the user and then sends that input to the database, well maybe you can corrupt the databases with SQL as the attacker without having direct access to the database server and that's what this module is all about.

State Management
This module is on State Management and everything that belongs to state management, for instance, cookies and sessions, and of course, security implications of that. But what is state? What you see here is the HTTP version 1. 1 specification from 1999, over 15 years ago, and this document, which still is valid as of today, HTTP 1. 1 is the most used HTTP version out there. It says that the Hypertext Transfer Protocol, HTTP, is a protocol that is, among other things, stateless. So it doesn't have a state, or in other words, the protocol doesn't remember anything. It doesn't store any data because well there is no state to be stored. This has always been a challenge for web applications because web applications they do need to remember something whether a user is logged in, what the user has in his or her shopping basket or cart, and many other pieces of information, state information for a current session or information that is retained so that if the user returns, the data is still there. There are solutions for that, but well with most technical compromises, there might be issues from a security point of view and that's what this module is all about from a PHP perspective, of course.

Cross-site Request Forgery (CSRF)
The next attack we would like to understand and defend our sites against is Cross-site Request Forgery, or CSRF, sometimes also spelled XSRF, but I prefer CSRF. Cross-site request forgery is a very dangerous attack. Some security researchers disagree with me here and rank CSRF far behind say cross-site scripting or SQL injection. But still, I believe cross-site request forgery is an underestimated attack and especially in the PHP space there is no built-in safeguard against that. Therefore, in this module, we will discuss cross-site request forgery, we will see it in action, also an associated attack, and then discuss how we can defend against that kind of attack.

Storing Passwords
Almost every application has secrets and the secret most commonly-used is a password or several passwords for users to login, for the administrator to log in, or any other passwords that are used, for instance, for calling remote services. And the question is, how do we store those passwords? And there are several approaches to that, some better, some worse, and we'll discuss what PHP brings to the table here. But the main threat is always that an attacker manages to get access to the source code of the application, which is bad enough. But still, if the source code contains say a key to decrypt a password or all passwords, then we have a real problem. If on the other hand, an attacker doesn't get access to the source code of an application, but to the database including all stored passwords there, well we have a problem too and all of our users have a problem too. There have been some high-profile cases in the last few months so that's why this module is pretty important. And we'll have a look at how should we store passwords.

Error Handling
This module is on Error Handling. Now what does error handling have to do with web security? I mean, no one really likes error messages because that means something went wrong. On the other hand, error messages are very valuable for two types of people. First of all, for us developers because not only do error messages tell us that something went wrong, usually, they also tell us what went wrong. And the second type of people that are interested in error messages are, of course, attackers because those error messages might contain valuable information for them too. Therefore, in this module, we will see how PHP can give us valuable error messages and how PHP can hide them from regular users.

Conclusion
In this brief and final module of this course, we will talk about essentially what we've done. And what better way to do that than having a look at the open web application security projects or OWASP's top 10 list, the list of the top 10 security risks for web applications. I'm recording this in the summer of 2016, and OWASP is currently gathering data for the 2016 edition of the top 10 list, which supposedly comes out in 2017. So I have to take the list that's current as of today and that's the list from 2013. The OWASP top 10 is usually updated every 3 years. However, in the last few years, those lists well they did change, they sometimes added a new type of risk, or they merged two risks into one, or they split a risk into two, stuff like that, but basically, the general risks are, of course, the same since well over a decade now. So we will have a look at that list and how we tackled that list from a PHP-centric view. By the way, the OWASP organization is technology agnostic. Their top 10 list is technology agnostic. So while we had a PHP look at things, all of those risks are also existing and valid and need to be tackled when you have to use a different server technology. So it's a very important list and we will have a look at it right now.