FIT5003 Software Security Software Security In a Nutshell Apostolos Fournaris 1 2Software Security Renewed interest “idea of engineering software so that it continues to function correctly under malicious attack” Existing software is riddled with design flaws and implementation bugs “any program, no matter how innocuous it seems, can harbor security holes” Threat Modelling (Architectural Risk Analysis) • Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege • To follow STRIDE, you decompose your system into relevant components, analyse each component for susceptibility to threats, and mitigate them 4 STRIDE Approach 5Threat Modelling Process 6Level 1 Diagram 7Standard Mitigations Attacks and Defenses 9Attack Methodology STRIDE Threat Model Threat Property we want Spoofing Authentication Tampering Integrity Repudiation Nonrepudiation Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization 10 Attack Methodology (STRIDE) Spoofing Impersonating another person/process Cookie Replay / Session Hijacking CSRF (Cross-site request forgery) 11 Attack Methodology (STRIDE) Tampering Unauthorized alternations XSS SQL Injection 12 Attack Methodology (STRIDE) Repudiation Denying claims/unproven actions Audit Log Deletion Insecure Backup 13 Attack Methodology (STRIDE) Information Disclosure Exposure to unauthorized person/process Eavesdropping Verbose Exception 14 Attack Methodology (STRIDE) Denial of Service (DOS) Service unavailability Website defacement 15 Attack Methodology (STRIDE) Elevation of Privilege Increasing person/process access level Logic Flow Attacks 16 Buffer Overflow Attack stack grows overwrite new address overwrite buffer[11] … … buffer[0] foo()’s stack overwritemain()’sstack buffer copy malicious code Trigger the execution of malicious payloads Developer approaches: • Use of safer functions like strncpy(), strncat() etc, safer dynamic link libraries that check the length of the data before copying. OS approaches: • ASLR (Address Space Layout Randomization) Compiler approaches: • Stack-Guard-> Stack Canaries Hardware approaches: • Non-Executable bit (NX bit) Stack Countermeasures 18 Obfuscation int main() { … … … … } } Abstraction Transformation Destroy module structure, classes, functions, etc.! Data Transformation Replace data structures with new representations! Control Transformation Destroy if-, while-, repeat-, etc.! Dynamic Transformation Make the program change at runtime! Secure Software Design Good Practises 1.Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases 2.Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated. Define security requirements. • Identify and document security requirements early in the development life cycle • Make sure that subsequent development artifacts are evaluated for compliance with those requirements. • When security requirements are not defined, the security of the resulting system cannot be effectively evaluated. • OWASP: “A security requirement is a statement of needed security functionality that ensures one of many different security properties of software is being satisfied. Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities” • Some standards with requirements: • ISO/IEC 27034; https://www.iso.org/obp/ui/#iso:std:iso-iec:27034:-1:ed-1:v1:en • OWASP Application Security Verification Standard; https://owasp.org/www-project-application-security-verification-standard/ • SAFECode “Fundamental Practices”; https://safecode.org/wp- content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Development_March_2018.pdf • SAFECode “Tactical Threat Modeling”; • SAMM; BSIMM; CWSS; CAPEC; • OWASP Threat Modeling Cheat Sheet Secure Design Principles Economy of mechanism: keep the design of the system as simple and small as possible. Fail-safe defaults: base access decisions on permission (a user is explicitly allowed access to a resource) rather than exclusion (a user is explicitly denied access to a resource). Complete mediation: every access to every object must be checked for authorization. Least privilege: every program and every user of the system should operate using the least set of privileges necessary to complete the job. Least common mechanism: minimize the amount of mechanism common to more than one user and depended on by all users. Psychological acceptability: it is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Compromise recording: it is sometimes suggested that mechanisms that reliably record that a compromise of information has occurred can be used in place of more elaborate mechanisms that completely prevent loss. Defense in depth: design the system so that it can resist attack even if a single security vulnerability is discovered or a single security feature is bypassed. Defense in depth may involve including multiple levels of security mechanisms or designing a system so that it crashes rather than allowing an attacker to gain complete control. Fail securely: a counterpoint to defense in depth is that a system should be designed to remain secure even if it encounters an error or crashes. Design for updating: no system is likely to remain free from security vulnerabilities forever, so developers should plan for the safe and reliable installation of security updates Secure Design Principles: Develop an Encryption Strategy • Definitions of what to protect: • Data in transition • Data in storage • Designation of mechanisms to use for encryption: There exist many algorithms and ways to used them (mode of encryption etc.) • Decide on a key and certificate management solution: Encrypting data is only one half of an encryption strategy. The other half is the solution to manage encryption keys and certificates. • Implement with cryptographic agility in mind: An encryption strategy should specify how applications and services should implement their encryption to enable transition to new cryptographic mechanisms, libraries and keys when the need arises. Example: Hard-coding encryption keys (or other secrets) within source code leaves them very vulnerable and must be avoided Secure Design Principles: Standardize Identity and Access Management • This provides consistency between components as well as clear guidance on how to verify the presence of the controls. • What to include/consider? • The mechanism by which users (both end-users and organization administrators) authenticate their identities. • The mechanism(s) by which one service or logical component authenticates to another, how the credentials are stored, and how they are rotated in a timely fashion • The mechanism(s) that authorizes the actions of each principal. Complete mediation • Authorization/authentication is linked: • The lease privilege policy.. • economy of mechanism, and • complete mediation Lease Privilege policy • Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges. • Default deny. Base access decisions on permission rather
than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted economy of mechanism • Keep it simple. Keep the design as simple and small as possible. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex. Secure Design Principles: Establish Log Requirements and Audit Practices • Use the operating system logging mechanism to capture the status changes of the software and record software critical events • What is a security critical event? • The content of the log files should always be determined by the group or groups that will need to consume the log file contents. • It is important not only to capture the critical information but to restrict information capture to only the needed data. • It is equally important to carefully identify what security information is relevant and needs to be logged, where the logs will be stored, for how long the logs will be retained and how the logs will be protected Why loging and auditing is needed? • In the event of a security-related incident, it is important to be able to piece together relevant details to determine what happened. • Well-designed application, system and security log files provide the ability to understand an application’s behavior and how it has been used at any moment in time. • They are the fundamental data sources that inform automated Security Information and Event Management (SIEM) systems alerting. • Example: Linux logging • /var/log/syslog or /var/log/messages: Generic log mechanism • /var/log/auth.log or /var/log/secure: store authentication logs, including both successful and failed logins and authentication methods. • /var/log/boot.log: a repository of all information related to booting and any messages logged during startup. • /var/log/kern: stores Kernel logs and warning data. This log is valuable for troubleshooting custom kernels as well. • /var/log/dmesg: messages relating to device drivers. The command dmesg can be used to view messages in this file. • /var/log/faillog: contains information all failed login attempts, which is useful for gaining insights on attempted security breaches, such as those attempting to hack login credentials as well as brute-force attacks. • /var/log/mysqld.log or /var/log/mysql.log Secure Coding Practices Establish Coding Standards and Conventions: • use built-in security features in the frameworks and tools selected and ensure that these are on by default • Create a secure code writing policy and enforce it to the software development team. In principle there will be mostly the same for various programming language. It might need some fine tuning fro each programming language. • Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set. • There are secure coding standards to help • Eg.: https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards Secure Coding Practices Handle Data securely, Input Validation • All user-originated input should be treated as untrusted • Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files • Ensure that each area in the application stack defends itself against the malicious input it may be vulnerable to. • Even with input validation, vulnerabilities remain as a result of processing data in unsafe ways, and therefore input validation should only be considered as a defense in depth approach. • Additional steps: • Encoding, which ensures the data is transformed so that it will be interpreted purely as data in the context where it is being used • Data binding, which prevents data from being interpreted as control logic by binding it to a specific data type Secure Coding Practices Input Validation • Validation can be broken down into checking origin, data size, lexical content, syntactic format, and semantics. • Origin checks can be done by checking the origin IP or requiring an access key to counteract DDoS attacks. • Data size checks can be done both at the system border and at object creation. • Lexical content checks can be done with a simple regular expression (regexp). • Syntax format checks might require a parser, which is more expensive in terms of CPU and memory. • Semantic checks often require looking at the data in the database, such as searching for an entity with a specific ID. • Earlier steps in the validation order are more economical to perform and protect the later, more expensive steps. If early checks fail, later steps can be skipped Secure Coding Practices Input validation After initial input validation and filtering ….still attacks are possible: Attackers use alternativ formulation of data input that can by pass the validation process. Thus, we need: • Canonicalization: is the process for converting data that establishes how these various equivalent forms of data are resolved into a “standard,” “normal” or canonical form. Canonical representation ensures that the various forms of an expression do not bypass any security or filter mechanisms • Input validation should be done AFTER canonicalization should be validated and either accepted or rejected. Only after canonicalization can a decision be made. • Sanitization can involve removing, replacing or encoding unwanted characters or escaping characters. Input from untrusted sources should always be sanitized • Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components. • Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks.. Secure Coding Practices Use Safe Functions Only • Many programming languages have functions and APIs whose security implications were not appreciated when initially introduced but are now widely regarded as dangerous. • Eg. Strcpy, strcat in C is vulnerable to buffer overflow • Java serializable objects • Javascript functions generate new code at runtime (eval, seTtimeout, etc.) and are a frequent source of code execution vulnerabilities. • The developers should counsel a security standard so that they avoid vulnerable functions Secure Coding Practices Handle Errors • Generated Errors can be exploited by attackers: • Information about the program • Data input manipulation • Even secret information disclosure • It’s better to fail fast in a controlled manner than to risk uncontrolled failures later. Fail fast by checking preconditions early in each method. • When notifying the user of an error, the technical details of the problem should not be revealed. • Details such as a stack trace or exception message provide little utility to most users, and thus degrade their user experience, but they provide insight to the attacker about the inner workings of the application • Error messages to users should be generic, and ideally from a usability perspective should direct users to perform an action helpful to them Secure Coding Practices Latest Compiler and Secure Compilers 1.Using the latest versions of compilers, linkers, interpreters and runtime environments: Commonly, as languages evolve over time they incorporate security features, and developers using previous compiler and toolchain versions cannot make use of these security improvements in their software 2.Secure complier options: Enable secure compiler
options and do not disable secure defaults for the sake of performance or backwards compatibility. 3.Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws. Defense in depth • Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. • For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment. Beyond Secure Designing and Coding: Testing and Quality assurance • Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. • Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. • Independent security reviews can lead to more secure systems. • External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions Security Testing • Static Analysis Security Testing (SAST) • Dynamic Analysis Security Testing (DAST) • Audits • Penetration Testing (red team) • Run Time Monitoring 38 Java Security (Now) Bootstrap class files System class files User class files Bytecode Verifier Bootstrap ClassLoader System ClassLoader ClassLoader Security Manager Protection Domains AccessController Operating System Hardware Permissions Keystore CodeSource(URL, Certificates) Policy Database 39 Java Security The class java.lang.SecurityManager is the focal point of authorization. SecurityManager is concrete, with a public constructor and appropriate checks in place to ensure that it can be invoked in an authorized manner. It consists of a number of check methods, e.g,: CheckPermission method is used to check to see if the requested access has the given permission based on policy. Security Manager 40 Java Security The bootstrap classloader is platform specific machine instructions that kick off the whole classloading process. Bootstrap classes – Classes that comprise the Java platform, including the classes in rt.jar and several other important jar files. The bootstrap classloader also takes care of loading all of the code needed to support the basic Java Runtime Environment (JRE), including classes in the java.util and the java.lang packages. Bootstrap Class Loader 41 Java Security classes from the system class path, which are set by the CLASSPATH environment variable System Class Loader java -Djava.system.class.loader=com.test.MyClassLoader MyApplication 42 Java Security Customized ClassLoader or a subclass from java.security.SecureClassLoader provides security features beyond the standard Java2 security model. ClassLoader loads classes into VM and is responsible for the namespaces at runtime. Namespaces as identically named identifiers can reference different objects. Primordial class loader loads bootstrap classes in a platform-dependent manner. System classes, some classes in java.* package are essential to the JVM and the runtime system are loaded by System ClassLoader. Class Loader when are classes loaded? 1. when the new bytecode is executed (for example, FooClass f = new FooClass();) 2. when the bytecodes make a static reference to a class (for example, System.out). 43 Java Security Checks a classfile for validity: Code should have only valid instructions and register use. Code does not overflow/underflow stack. Does not convert data types illegally. Accesses objects correct types. Method calls use correct number and types of parameters. References to other classes use legal names. Byte Code Verifier 44 Java Security CodeSource Java Code is downloaded over a network, so the code’s signature and author are critical to maintain a secure environment. The object java.security.CodeSource describes a piece of code. CodeSource encapsulates the code’s origin, which is specified as an URL. Set of digital certificates containing public keys corresponding to the set of private keys are used to sign the code 45 Java Security Keystore is a password-protected database that holds private keys and certificates. The password is selected at the time of creation. Each database entry can be guarded by its own password for extra security. Certificates accepted into the keystore are considered to be trusted. Keystore 46 Access Policy The policy file(s) specify what permissions are allowed for code from a specified code source, and executed by a specified principal. $JAVA_HOME/jre/lib/security/java.security $JAVA_HOME/jre/lib/security/java.policy $ /usr/libexec/java_home /Library/Java/JavaVirtualMachines/ jdk1.8.0_152.jdk/Contents/Home 47 Access Policy $JAVA_HOME/jre/lib/security/java.policy grant codeBase “file:${{java.ext.dirs}}/*” { permission java.security.AllPermission; }; grant { permission java.util.PropertyPermission “java.version”, “read”; }; policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy $JAVA_HOME/jre/lib/security/java.security 48 Access Controller static boolean unaligned() { if (unalignedKnown) return unaligned; String arch = AccessController.doPrivileged( new sun.security.action.GetPropertyAction(“os.arch”)); unaligned = arch.equals(“i386”) || arch.equals(“x86”) || arch.equals(“amd64”) || arch.equals(“x86_64”); unalignedKnown = true; return unaligned; } get_property permission 49 Access Controller static boolean unaligned() { if (unalignedKnown) return unaligned; String arch = AccessController.doPrivileged( new sun.security.action.GetPropertyAction(“os.arch”)); unaligned = arch.equals(“i386”) || arch.equals(“x86”) || arch.equals(“amd64”) || arch.equals(“x86_64”); unalignedKnown = true; return unaligned; } get_property permission Class Method Constructor Field Modifier Others Reflection Reflection Method[] methods = MyObject.class.getMethods(); for(Method method : methods){ System.out.println(“method = ” + method.getName()); } This example obtains the Class object from the class called MyObject. Using the class object the example gets a list of the methods in that class, iterates the methods and print out their names. Reflection How to get Metadata of Class? 1 cls.getName(); 2 cls.getModifiers(); 3 cls.getInterfaces(); 4 cls.getSuperclass().getName(); import java.io.Serializable; public abstract class fit5003base implements Serializable,Cloneable { } 12 3 4 Reflection How to get Metadata of Variable? from the specified class as well as from its super class Field[] field1 = cls.getFields(); //from the specified class only Field[] fiel2 = cls.getDeclaredFields(); Java Deserialization in a Nutshell Serializable creates: •a public hidden constructor •a public interface to all fields of that class Deserialization is Object Creation and Initialization •Without invoking the actual class’s constructor Any available class can be deserialized •Calling ObjectInputStream.readObject() using untrusted data can result in malicious behavior 55 Public Key Encryption Generating Key KeyPairGenerator keyGen = KeyPairGenerator.getInstance(“RSA”); keyGen.initialize(512); KeyPair pair = keyGen.generateKeyPair(); PublicKey publicKey = pair.getPublic(); PrivateKey privateKey = pair.getPrivate(); Cipher cipher = Cipher.getInstance(“RSA”); cipher.init(Cipher.ENCRYPT_MODE, publickey); byte[] buf = cipher.doFinal(“xyz”.getBytes()); System.out.println(new String(buf)); Encrypt Decrypt Cipher cipher2 = Cipher.getInstance(“RSA”); cipher2.init(Cipher.DECRYPT_MODE, privatekey); byte[] buf2 = cipher2.doFinal(buf); System.out.println(new String(buf2)); publicKey privateKey 56 Android Basics Activity Serv
ice Content Provider Broadcast Receiver Component – Explicit – The intent “explicitly” specifies which component it wants to talk to – It specifies the target’s full package name / component – Implicit – The intent just describes the type of action to perform (and, optionally, some data) – Good source of info / tutorial: link 57 Explicit vs. Implicit Intents 58 Activity1 Activity2 ICC methods: e.g., startActivity(Intent) Action: test.ACTION Category: test.CATEGORY Activity3 Implicit Intent (example) 59 Activity1 Activity2 ICC methods: e.g., startActivity(Intent) destComp: Activity2 Activity3 Explicit Intent (example) 60 ICC Issues Activity1 Activity2 MaliciousActivity Want to Send SMS but does not declare SEND_SMS permission Declared SEND_SMS permission Exploit SEND_SMS 61 ICC Issues Component1 Component2 Activity Hijacking Service Hijacking Broadcast Theft Activity Launch Service Launch Broadcast Injection Malicious Components Malicious Components Hijacking Launch 62 Android Permission System activity restricts access to the activity checked when starting activity throw SecurityException if caller does not have required permission service restricts who can start, stop or bind to the service receiver restricts who can send broadcasts to the BroadcastReceiver checked at delivery, after broadcast was sent does not throw exception in case of permission failure provider restrict who can access the data read and write permissions checked when performing operations(e.g. query, insert) package=”com.example.awesomeapp”> … 63 Permission Request 64 Clone Detection Piggybacked App Original App Malicious Payload Carrier Rider Hook Wu Zhou, Yajin Zhou, Michael Grace, Xuxian Jiang, and Shihong Zou. Fast, scalable detection of “piggybacked” mobile applications. In CODASPY ’13, pages 185–196, New York, NY, USA, 2013 65 Clone Detection Similarity Comparison Symptom Discovery (Un)Supervised Learning Runtime Monitoring 66 Privacy Leak source sink Taint Analysis public class Activity_A { void onCreate(Bundle b) { String id = telManager.getDeviceId(); //… String alias = id; String number = “+3524666445556”; sms.sendTextMessage(number, null, alias, null, null); } } 67 source sink Privacy Leak White Box: Static Code Analysis Black Box Fuzzing 68 Security Testing (Methodology) Goals: Find common bugs quickly Allow humans to focus on parts of code likely to be risky Limitations Cannot find design level vulnerabilities Cannot make a judgement of importance of a found vulnerability Only detect vulnerabilities in tool’s “rule database” Suffer from errors: False positive: reported bugs are not really bugs False negative: missed reporting a real bug 69 Static Code Analysis 70 Control-Flow Graph (CFG) read(x); while (X<10){ X←X-1; A[X]←10; if (X=4) X←X-2; }; Y←X+5; Exercise! ENTRYB0: read(x); if (x>=10) goto B4B1: X=X-1 A[X]=10; If (X=4)goto B3; B2: EXITB5: Y=x+5B4: X=x-2B3: Simple (usually free) search-based tools Examples: FlawFinder, RATS, ITS4, … Search source file for “dangerous functions” known to cause common vulnerabilities e.g. strcpy(), gets() for buffer overflows Produces list of “hits” and ranks them by risk Better than just pure search Ignores commented code Ignores strings Some risk ranking But little attempt to analyze relationships within code 71 Static Code Analysis 72 Fuzz Testing Automaticaly generate test cases Many slightly anomalous test cases are input into a target interface Application is monitored for errors Inputs are generally either file based (.pdf, .png, .wav, .mpg) Or network based… http, SNMP, SOAP Or other… e.g. crashme() 73 Fuzz Testing (Mutation) Strengths Super easy to setup and automate Little to no protocol knowledge required Weaknesses Limited by initial corpus May fail for protocols with checksums, those which depend on challenge response, etc. 74 Fuzz Testing (Generation-based) Strengths Completeness Can deal with complex dependencies e.g. checksums Weaknesses Have to have spec of protocol Often can find good tools for existing protocols e.g. http, SNMP Writing generator can be labor intensive for complex protocols The spec is not the code Web Technologies 75 3-Tier Web Architecture: Client-Server-Database Interface tier Logic tier Storage tier Client Web Browser (IE, Chrome, Firefox,… ) Web Server (IIS, Apache, …) Database / Backend server (MySQL, MS-SQL, Oracle, …) HTTP / HTTPS Browser script (HTML / HTML5, CSS, Javascript, VBScript, DOM/Ajax/ JSON/XML, browser extensions: Java applets, ActiveX,Flash,Silverlight, … ) SQL, SOAP /XML,…Server Script (PHP, Java, ASP.NET, Python, Perl, …) Database language (MySQL, MS-SQL, Oracle, …) Web Security Overview Server Side: Database Query Languages • Structured Query Language (SQL) • Variants: Oracle, MS-SQL, MySQL • SQL manages relational databases: • Database consists of tables • Each table has a number of rows (database records) , e.g. a row per user • Each row has a number of columns (data fields), e.g. “email address”, “name”, “age”,… • SQL language queries: read, update, add, or delete data • E.g. SELECT email FROM users WHERE name = ‘Li’ • Returns email column value for rows in users table where the name column value = ‘Li’. 76 Web Security (Server Side) Client Side: Browser Security Policy •Browser security goals: • User can safely visit any web site • Even malicious web sites cannot access / modify client’s local disk / memory information without user’s permission • Browser runs Javascript in a sandbox – access OS / file system via API enforcing access control • E.g. Upload authorization via file picker dialog. • However, a web site can still track users (e.g. cookies,…)! • User can safely visit multiple web sites in same browser: • Open page from site X cannot interfere (read/write) with open page from site Y • E.g. banking site window should not be read by script in social networking window • Enforced via the browser Same Origin Policy 77 Web Security (Browser Side) • Another method to bypass escaping: second-order SQLi • Suppose ‘ character in user input string was escaped (replaced by ’’) by web application A second-order vulnerability for string inputs may still be exploitable: • Consider app registering users in database and then retrieving • Attack first phase: attacker registers escaped input into database • Attacker registers into database user name such as • bob ‘ OR 5=5 — • Due to escaping of ‘ character, this user name is processed correctly, and inserted into database • No injected code execution in phase 1. But now the stored username string is bob‘ OR 5=5 — without escaping… 78 SQL Injection Vulnerabilities • How to defend effectively against SQLi? • Filtering / escaping is tricky / can often be bypassed • Preferred robust solution: parameterized queries • A.k.a prepared statements • Fix root cause of injection problem: SQL database treating user data as code • Idea: Application passes the SQL statement to SQL server in two distinct phases: • Phase 1 (pass code): Pass desired SQL statement with placeholders (? Symbol) for data values, e.g. $stmt = $mysqli->prepare(“SELECT District FROM City WHERE name=?”); • Phase 2 (pass data): Pass the data values for placeholders, e.g.: $stmt->bind_param(“s”, $name); • Finally, execute and get result, e.g.: •$stmt->execute(); /* This executes the prepared statement $stmt */ •$result = $stmt->get_result(); /* Get result into $result */ •$stmt->close(); /* This completes the prepared statement */ • Any malicious user data passed in Phase 2 will be interpreted as data, not code. 79 SQL Injection Vulnerabilities 6REFLECTED XSS Another Practical example 1. The attacker crafts a URL containing a malicious string and sends it to the victim. 2. The victim is tricked by the attacker into requesting the URL from the website. 3. The webs
ite includes the malicious string from the URL in the response. 4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server. https://excess-xss.com/ ATTACK SCENARIO The steps involved in a stored XSS attack A Practical Example 1. The attacker uses one of the website’s forms to insert a malicious string into the website’s database. 2. The victim requests a page from the website. 3. The website includes the malicious string from the database in the response and sends it to the victim. 4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server. https://excess-xss.com/ Attacker can craft a URL containing JavaScript code as the value of the message parameter This code will be dynamically written into the page and executed in the same way as if the server had returned it E.g. http://domain- a.net/error/18/Error.ashx?message= 28 DOM-BASED XSS Another Practical example 1. The attacker crafts a URL containing a malicious string and sends it to the victim. 2. The victim is tricked by the attacker into requesting the URL from the website. 3. The website receives the request, but does not include the malicious string in the response. 4. The victim’s browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page. 5. The victim’s browser executes the malicious script inserted into the page, sending the victim’s cookies to the attacker’s server. https://excess-xss.com/ Cross-Site Request Forgeries (CSRF) • Recall: Cross-Site Scripting (XSS) vulnerabilities need attacker script to be reflected back from application (step 4): • XSS prevented if application output is filtered/encoded to avoid reflecting attacker script – step 4 is blocked. • BUT, steps 2 and 3 still possible! Can this still be exploited? • Sometimes, YES, via OSRF/CSRF vulnerabilities 86 Cross-Site Request Forgeries (CSRF) 87 • Session Fixation Vulnerabilities • Suppose: • same session token used for all requests • session token = URL parameter in user request • Attack: 1. Attacker logs in anonymously to http://amazon.com • Obtains session token: SESS=2as435sdf34251sdg 2. Attacker sends user john a URL with attacker’s session token • E.g. user gets email with URL http://amazon.com/login.php?SESS=2as435sdf34251sdg 3. User clicks attacker’s URL and logs in to Amazon: • Amazon associates attacker’s token with logged in user john 4. Attacker uses token to hijack user’s session: • Attacker requests http://amazon.com/browse.php?SESS=2as435sdf34251sdg • Gets access to john’s amazon session • Defense: John gets new session token from Amazon at step 3, attacker’s session id not accepted in step 4. 88 Session Management 89 Blockchain 90 Smart Contract Tx-nTx-1 Block Mining Miners Tx-2 Block A set of TXs Previous block New State Root Receipt Root Nonce SHA3(Block) < D Broadcast Block Verify transactions & execute all code to update the state 91 Smart Contract Code execution • Every (full) node on the blockchain processes every transaction and stores the entire state P6 P5 P4 P3 P2 P1 This is a new block! I’m a leader This is a new block! This is a new block! This is a new block! This is a new block! This is a new block! 92 Smart Contract • Halting problem • Cannot tell whether or not a program will run infinitely • A malicious miner can DoS attack full nodes by including lots of computation in their txs • Full nodes attacked when verifying the block uint i = 1; while (i++ > 0) { donothing(); } 93 Smart Contract Solution: Gas Charge fee per computational step (“gas”). Special gas fees for operations that take up storage Sender has to pay for the gas 94 The DAO Attack A DAO is a Decentralized Autonomous Organization. Its goal is to codify the rules and decision making apparatus of an organization, eliminating the need for documents and people in governing, creating a structure with decentralized control. 95 Unchecked CALL Return Values The return value of send() is not checked 96 eEXAMs eAssessment Platform on 25th of November (a 2h 10min exam) Sample eExam next week Consultations will be announced on the Ed platform 20 MCQs and 6-8 Short Essay Questions Related to lectures AND the tutorials/labs The answers can be derived from the slides/labs but you will also have to make some critical reflection on the existing resources. Thank you! Hope you enjoyed the Unit 97 欢迎咨询51作业君
