WIXLIB

COMP 10065: Module 5c Guide Sam Scott, Mohawk College, 2020The topic of this submodule is web app security. Web app designers face special concernswhen it comes to protecting their apps and their user’s data from online vandals and burglars.This module presents an overview of some of the main security issues facing web app designersalong with some coding practices and tools that can help to mitigate these threats.1. The Danger of User InputServer-side PHP programs routinely receive input from users through HTTP Requestparameters sent from HTML forms. They take this user input and incorporate it into web pagesand SQL queries. In other words, user input is used to write code that gets executed on theclient or server machine. If programmers are not careful about how they handle this user input,they open their apps to various kinds of attacks. One common kind of attack is code injection.HTML Code InjectionTo see a simple, and relatively harmless, code injection attack in action, try the file hackMe.phpfrom the examples on Canvas. This app receives an HTTP Request parameter called param andechoes it to the page without using filter input to sanitize it first.To see why this is a problem, try the GET parameter show below in the URL:hackMe.php?param script location.reload() /script This benign hack causes a JavaScript command to be injected into the HTML code for the page.The command refreshes the page as soon as it’s loaded, effectively disabling it and wastingbrowser cycles and bandwidth. At the time of writing, this hack works on Firefox and IE but noton Chrome, which is smart enough to detect it (check the messages in the Chrome DeveloperConsole).The Problem: GETIf you take a look at the hackMe.php code, you’ll see that it is accessing the get parameterusing a method that has not yet been officially introduced in this course.echo " p GET[param] /p ";The above statement is retrieving the request parameter from a superglobal associative arraycalled GET instead of using filter input to do the retrieval. The superblogal POST is alsoavailable for post parameters and REQUEST contains all get and post parameters together aswell as any cookies received with the request. These variables are the oldest and mostestablished ways of receiving parameters in PHP.1

The Solution: Validate and SanitizeThe fix for the code injection problem above is easy: sanitize the parameter using filter inputbefore placing it on the page. The hackMeFixed.php example on Canvas does just that. It is notsusceptible to this code injection.There are other ways to sanitize and validate your parameters but filter input is considered abest practice solution by many programmers because it allows you to avoid using GET and POST anywhere in your code. If you never access these variables directly, then it is much lesslikely that you will accidentally expose yourself to a code injection attack.The Problem of Run-time ErrorsMaking sure you always use filter input with the correct filter type and check its return valuewill also insulate your code from run-time errors. Run-time errors are to be avoided becausethey can lead to a negative user experience, but they can also sometimes tip off a clever hackerabout other vulnerabilities in your system.For example, if your server is configured to display error messages and you access the POSTarray looking for a userid parameter, the user might see something like the message below.Notice: Undefined index: userid in https:\\example.com\library\utilities.php on line 2This error exposes:1. The language this part of the app is written in,2. The name of the parameter it receives,3. The URL of one of the PHP files involved in the app (which might not have been visible ifit was loaded using an include statement).All of this information could be used by a clever hacker to figure out a way to gain unauthorizedaccess to your app or your user data. For this reason, most production servers turn off errorreporting entirely. Error reporting is used only during development, and only on internaldevelopment servers. (We have left error reporting active on CSUnix only because it is used forteaching and learning.) Still, any server can be accidentally misconfigured, so you should alwaysavoid any possibility of run-time errors to avoid exposing vulnerabilities to a malicious user.2

SQL Code Injection AttacksIn this course, we showed you how to use PDO to prepare and execute statements withparameters (i.e. question marks) that get filled in, often using HTTP Request Parameters, whenyou execute.But an alternative and very dangerous practice would be to simply concatenate data from theuser directly into the command string.Here’s an example: id filter input(INPUT POST, "id", FILTER SANITIZE SPECIAL CHARS); deletecommand "DELETE FROM MyTable WHERE ID id"; stmt dbh- prepare( deletecommand); stmt- execute();User input concatenated directlyinto the SQL command string.The code above is vulnerable to an SQL Injection attack in which a hacker types some SQLsyntax into your form which then gets concatenated (i.e. injected) into your SQL commandstring and wreaks havoc on your database.A simple attack on the code above would be for the user to send a pollid parameter set tosomething like “1 OR 1”. In that case the command string becomesDELETE FROM MyTable WHERE ID 1 OR 1;Since 1 is interpreted as TRUE in SQL, the above is equivalent to:DELETE FROM MyTable WHERE (ID 1) OR (TRUE);The WHERE clause evaluates to TRUE for every row, so every row in the table gets deleted.Using other SQL Injection attacks, a clever hacker might be able to retrieve passwords or othersensitive data, login as an administrator, etc. The SQL Injection section of the SQL tutorial onW3Schools has a few other examples of possible injection attacks.Try Your own SQL InjectionYou can try out the example above using the sql injection example on Canvas.1. Import newtesttable.sql using phpMyAdmin. Browse the table.2. Load index.html and use the form to delete one record. Verify using phpMyAdmin.3. Load index.html again, and this time use “1 or 1” as the delete ID. Verify that the attackworked in phpMyAdmin.If you change index.html so that the form directs to deleteSafe.php instead of delete.php, theabove attack will not work. The deleteSafe.php version of the code uses a prepared statement3

parameter (a question mark) in the SQL command string, and then sends the data to fill in theparameter as an argument to the execute method.How Do Parameters Help?One way to think of the difference between using prepared statement parameters and justconcatenating the command string together is that the prepare method compiles the commandinto a function which accepts an argument and executes the command using that argument.Let’s call the function created by the prepare method in the above example deleteById. Then if id contains the string “1 OR 1” the execute statement in the above example calls deleteByIdlike this:deleteById(“1 OR 1”);The function goes to the database looking for rows with id set to “1 OR 1”. Since there are nosuch rows, the function deletes nothing. The parameter helped because input from the userwas treated as data rather than being executed as code.This SQL Injection example could also have been neutralized using FILTER VALIDATE INTinstead of FILTER SANITIZE SPECIAL CHARACTERS because “1 OR 1” is not an integer andwould have caused filter input to return false. To be as safe as possible, it is a best practice touse the correct input filter and also use parameters in the SQL query string as well. If multiplelines of defense are always in place, then all the code you write will be safer.Client Side ValidationThe story so far is that you must validate and sanitize all the data coming into your server, andyou must use prepared statement parameters for SQL so that your code is not vulnerable toinjection attacks and other possible hacks. But what if we carefully construct HTML forms anduse HTML attributes and JavaScript event listeners to validate the forms and prevent the userfrom submitting invalid data in the first place?For example, an HTML form could:-use the required attribute on an input element to prevent empty parameters,use type "number", type "email", etc. to force a parameter into the proper format,use a select element to force the user to pick from a list of valid choices,use JavaScript event listeners on the submit, input, or change events can to catch otherissues, even as the user types,etc.Using all the above tricks and more, you can lock down the user very effectively. Butunfortunately, client-side validation is not enough to make your app safe from attack. Theserver has no way of knowing where an HTTP Request is coming from or how it was created. Aclever user can enter the browser’s developer tools to turn off all the client-side validation, orcreate their own HTTP Request using a form or script written for that purpose.4

But client-side validation is still important for other reasons.-Client-side validation creates a nicer user experience. Users will not have to wait for apage load to find out they have submitted bad data, and with JavaScript, you can alertthem to problems as they fill in the form.-Client-side validation minimizes wasted resources by preventing HTTP Requestscontaining invalid data. Every bad HTTP Request wastes bandwidth and processing timeon the server, which has to create the HTTP Response, run scripts, and possibly executedatabase queries for the invalid request.The bottom line is that you must validate user input on both the server-side and the clientside of your app.5

2. Hiding Sensitive InformationSensitive information should be kept hidden as much as possible, even from trusted employees.Passwords, credit card numbers, and other sensitive data should not be visible on the device,should not be visible in transmission, and should not even be visible in the database oranywhere else on the server.Hiding Information on the DeviceHiding information on the device means making sure that people and surveillance devices inthe user’s environment do not have a view of it.MaskingMasking information means blocking all or part of it when displaying it on the page.Passwords can be masked using an input element with type "password". This shows thelength of the password, but not its contents.(JavaScript event listeners can also be used tocapture inputs and change the value attribute,masking the length of the password as well.)Credit card numbers should be masked, but inpractice, it is frustrating for the user to not be able tosee a long number while entering it. So, most appsdo not mask during initial entry but do mask most ofthe credit card number when echoing it forconfirmation.POST ParametersSensitive information should always be sent using an HTTP Post Request. This does not keepthe information safe from hackers, but it does stop the information from being viewed,bookmarked, copied, and pasted.Oops! Password sent in a GET requestcan be seen by anyone nearby.6