P3 - Explain the security risks and protection mechanisms involved in website performance Assessment 1 Task 3 Explain the following security risks SQL Injection Cross Site Scripting XSS Brute Force Attack/Dictionary Attack Explain the following protection mechanisms Adherence to standards e.g. Data Protection Laws Encryption
Security Risks - SQL Injection SQL is a language that has been around before the internet It allows you to enter commands into a database. Adding, deleting, select data etc. The language itself is very easy to learn and is almost plan English Example SELECT * FROM Customers;
Security Risks - SQL Injection SELECT * FROM Users WHERE Username= Owen'; Users
Security Risks - SQL Injection SELECT * FROM Users WHERE Username= Owen ; Escape Users
Security Risks - SQL Injection SELECT * FROM Users WHERE Username= Owen ;DROP DATABASE User Query 1 Users Escape to new query
Security Risks - SQL Injection Convert Number Plate to Digital Form INSERT INTO SpeedCam(NumberPlate) VALUES ( ARD2 ONR ) SpeedCam
Security Risks - SQL Injection
Security Risks - SQL Injection In 2010 a hacker attacked the MOD s royal marine website Using simple SQL commands they were able to drop the databases, rendering the website unusable
Security Risks - SQL Injection The Fixes mysqli_real_escape_string() Strips out special characters from the SQL query. $firstname = mysqli_real_escape_string($con, $_POST['firstname']); $lastname = mysqli_real_escape_string($con, $_POST['lastname']); $age = mysqli_real_escape_string($con, $_POST['age']); $sql="insert INTO Persons (FirstName, LastName, Age) VALUES ('$firstname', '$lastname', '$age')";
Security Risks - SQL Injection The Fixes SELECT * FROM Users WHERE Username= Owen / ; Special Character Stripped out Users
Security Risks - SQL Injection The Fixes Prepared Statements A way of controlling the way of data is inserted into the database SELECT * FROM Users WHERE Username=?'; The Data inserted runs though a control system. It will not run any commands. It will only place the data directly into the databases.
Security Risks - Cross Site Scripting XSS Web pages are made of HTML tags <HTML> <b>hello, World</b> </HTML> What happens when we try place a < symbol in our code? <HTML> <b>10 < 20 </b> </HTML>
Security Risks - Cross Site Scripting XSS In the past < symbols would screw up your scripts. So websites process less then symbols as < Well made web apps process a < (less than) and converts them into: < Processed <HTML> <b>10 < 20 </b> </HTML> Unprocessed <HTML> <b>10 < 20 </b> </HTML>
Security Risks - Cross Site Scripting XSS If we allowed our less then symbols to be unprocessed this could mess up our code. Causing error on the page. It could also mean we could run scripts inside our webpage forms
Security Risks - Cross Site Scripting XSS PayPal servers apparently fail to check strings entered in the German version of the site-wide search field PayPal now run a program where users find a report bugs Instead of going public you tell them and get rewarded
Security Risks - Cross Site Scripting XSS Vulnerability.paypal.com and PayPal subsidiary websites Partner sites (www.paypal-.com) Remote Code Execution Up to $10,000 $1,500 SQL Injection Up to $5,000 $1,000 Authentication Bypass Up to $3,000 $1,000 Cross-Site Scripting (XSS) $750 $100 Information Disclosure of Sensitive Data $750 $100 Clickjacking $750 0 Cross-Site Request Forgery (CSRF) $750 0 https://www.paypal.com/us/webapps/mpp/security/reporting-security-issues
Security Risks - Cross Site Scripting XSS Theses < are the problems. They are being processed wrong. We need to make sure in our form code they are being processed and changed from This < into this < Lecturer: Owen Funnell
Security Risks - Cross Site Scripting XSS The Fixes We use a filter which can filter out any special characters. PHP functions like htmlspecialchars If the $input was= $input = htmlspecialchars($input, ENT_QUOTES); <script>alert("this is a XSS Exploit Test")</script> this function would convert it into <script>alert("this is a XSS Exploit Test") </script> And the website would input into the database. It would not run
Security Risks - Brute Force Attacks A password and cryptography attack that does not attempt to decrypt any information, but continue to try a list of different passwords, words, or letters. For example, a simple brute-force attack may have a dictionary of all words or commonly used passwords and cycle through those words until it gains access to the account.
Security Risks - Brute Force Attacks User1 Password 1 INCORRECT User1 Password 2 INCORRECT User1 Password 3 CORRECT Lecturer: Owen Funnell
Security Risks - Brute Force Attacks Lecturer: Owen Funnell
Security Risks - Brute Force Attacks The Fixes Captcha The randomized image cannot be read by computers. So a automated attack will fail Passwords Setting rules for user passwords can help stop brute force attacks. Strong password should have Capital letters, numbers and symbols (@!? Etc.) https://howsecureismypassword.net/ Lecturer: Owen Funnell
Protection Mechanisms Adherence to standards - Data Protection The Data Protection Act (DPA) is a law designed to protect personal data stored on computers or in an organised paper filing system. With more and more organisations using computers to store and process personal information there was a danger the information could be misused or get into the wrong hands. Data Protection The 1998 Data Protection Act was passed by Parliament to control the way information is handled and to give legal rights to people who have information stored about them. In its simplest form it lays out the rules organisation must follow with data For the Assessment you must discuss the law and what it includes
Protection Mechanisms Adherence to standards - Data Protection It must be collected and used fairly and inside the law It can only be used for those registered purposes and only be disclosed to those people mentioned in the register entry. You cannot give it away or sell it unless you said you would to begin with The information must be kept safe and secure. This includes keeping the information backed up and away from any unauthorised access. It would be wrong to leave personal data open to be viewed by just anyone.
User Authentication The Analogy Web App Analogy The Admin is going to create a user in the database Purchasing tickets for a concert At that point we have the ability to attend, even though we haven't attended yet. The user comes to the site, they log in via a login form Waiting in line to pick up your tickets The application authenticates the user. takes that username and password and sees that they are valid The user requests additional password protected pages Presenting your identification, getting your tickets and then getting a hand stamp so that you can then enter. And you can then go where you want inside the event Showing your handstamp to security to go to other places in the venue You can avoid the line, you can simply just re-enter, because we know that you have that stamp, we know that you're allowed to be there. User logs out Like washing away the handstamp. It essentially says at that point, you're no longer allowed to be in the event, you need a new ticket to get back in. You need to start the process over again.
Encrypting Passwords Hashing is the term for the process of taking a string of data and apply a mathematical function to it to produce a unique string of output. Password Hashing Applying an algorithm to a password, to generate an encrypted string. Example - $2y$10$NmZiNzcxMzhiY2E0NTg2YO9X4eeRSo03H6r0A5bqHkZnF1hI8sLX Encrypting hash won't give away the password and the original password can't be reverse engineered even with lots of computing power. The hash that it generates for passwords will be unique, it can only be recreated by using the same password with the same hashing algorithm The only way to have a password match will be to know the original password
Encrypting Passwords The most important rule about passwords NEVER EVER EVER store passwords in the database as plain text, always encrypt them. If they're in plain text, then anyone who gains access to your database will have every user's password. One Way Encryption The principle: the same inputs to the same hashing algorithm will always result in the same output Take the password, encrypt it, and then we'll store the result in the database. Then when a user comes to our site and tries to log in, we'll take their attempted password, we'll pass it to the same hashing algorithm. If the output matches what we have stored. If the output is the same, then we know that the input was correct. If the output's different, we'll know that the input wasn't.
Encrypting Passwords Encrypt Secret = $2y$10$NmZiNzcxMzhiY2E0NTg2YO9X4eeRSo03H6r0A5bqHkZnF1hI8sLX Decrypt $2y$10$NmZiNzcxMzhiY2E0NTg2YO9X4eeRSo03H6r0A5bqHkZnF1hI8sLX = Secret
Encrypting Passwords Dozens of hashing algorithms, all for different uses not all of them are suitable for password hashing MD5 SHA-1 (Used at the college) SHA-2 (SHA-256/SHA-512) Whirlpool Tiger AES Blowfish Now MD5 used to be a good choice and lots of people used it, but it's not recommended anymore. A security flaw has been discovered in it. The weakness is not simple to exploit, but it is enough to make it less than ideal
Encrypting Passwords SHA-2 as a minimum level of encryption for the US government Blowfish offers a high-level of security in the public domain no patent free to use included with PHP 5.3 and later The Con Its very slow! Is that a good thing?