Web Application and cloud Security CH4.pptm.pptx

Web Application and cloud Security CHAPTER4 SQL INJECTION- HTTPS- AUTHENTICATION “ SQL INJECTION ”  SQL injection SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application ma...

Web Application and cloud Security CHAPTER4 SQL INJECTION- HTTPS- AUTHENTICATION “ SQL INJECTION ”  SQL injection SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This can allow an attacker to view data that they are not normally able to retrieve. This might include data that belongs to other users, or any other data that the application can access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior. In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure. It can also enable them to perform denial-of- service attacks.  What is the impact of a successful SQL ?injection attack A successful SQL injection attack can result in unauthorized access to sensitive data, such as: 1. Passwords. 2. Credit card details. 3. Personal user information. SQL injection attacks have been used in many high-profile data breaches over the years. These have caused reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.  Types of SQL Injections SQL injections typically fall under three categories: In-band SQLi (Classic), Inferential SQLi (Blind) and Out-of-band SQLi. You can classify SQL injections types based on the methods they use to access backend data and their damage potential.  In-band SQLi  Inferential (Blind) SQLi  Out-of-band SQLi  In-band SQLi The attacker uses the same channel of communication to launch their attacks and to gather their results. In-band SQLi’s simplicity and efficiency make it one of the most common types of SQLi attack. There are two sub-variations of this method: Error-based SQLi—the attacker performs actions that cause the database to produce error messages. The attacker can potentially use the data provided by these error messages to gather information about the structure of the database. Union-based SQLi—this technique takes advantage of the UNION SQL operator, which fuses multiple select statements generated by the database to get a single HTTP response. This response may contain data that can be leveraged by the attacker.  Inferential (Blind) SQLi The attacker sends data payloads to the server and observes the response and behavior of the server to learn more about its structure. This method is called blind SQLi because the data is not transferred from the website database to the attacker, thus the attacker cannot see information about the attack in-band. Blind SQL injections rely on the response and behavioral patterns of the server so they are typically slower to execute but may be just as harmful. Blind SQL injections can be classified as follows: Boolean—that attacker sends a SQL query to the database prompting the application to return a result. The result will vary depending on whether the query is true or false. Based on the result, the information within the HTTP response will modify or stay unchanged. The attacker can then work out if the message generated a true or false result. Time-based—attacker sends a SQL query to the database, which makes the database wait (for a period in seconds) before it can react. The attacker can see from the time the database takes to respond, whether a query is true or false. Based on the result, an HTTP response will be generated instantly or after a waiting period. The attacker can thus work out if the message they used returned true or false, without relying on data from the database.  Out-of-band SQLi The attacker can only carry out this form of attack when certain features are enabled on the database server used by the web application. This form of attack is primarily used as an alternative to the in-band and inferential SQLi techniques. Out-of-band SQLi is performed when the attacker can’t use the same channel to launch the attack and gather information, or when a server is too slow or unstable for these actions to be performed. These techniques count on the capacity of the server to create DNS or HTTP requests to transfer data to an attacker.  How to detect SQL injection vulnerabilities You can detect SQL injection manually using a systematic set of tests against every entry point in the application. To do this, you would typically submit: 1. The single quote character ' and look for errors or other anomalies. 2. Some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and look for systematic differences in the application responses. 3. Boolean conditions such as OR 1=1 and OR 1=2, and look for differences in the application's responses. 4. Payloads designed to trigger time delays when executed within a SQL query, and look for differences in the time taken to respond. 5. OAST payloads designed to trigger an out-of-band network interaction when executed within a SQL query, and monitor any resulting interactions. Alternatively, you can find the majority of SQL injection vulnerabilities quickly and reliably using Burp Scanner.  Detecting SQL injection vulnerabilities  SQLinjection in different parts of the query  SQL injection in different contexts  SQL injection in different parts of the query Most SQL injection vulnerabilities occur within the WHERE clause of a SELECT query. Most experienced testers are familiar with this type of SQL injection. However, SQL injection vulnerabilities can occur at any location within the query, and within different query types. Some other common locations where SQL injection arises are: 1. In UPDATE statements, within the updated values or the WHERE clause. 2. In INSERT statements, within the inserted values. 3. In SELECT statements, within the table or column name. 4. In SELECT statements, within the ORDER BY clause.  SQL injection in different contexts In the previous labs, you used the query string to inject your malicious SQL payload. However, you can perform SQL injection attacks using any controllable input that is processed as a SQL query by the application. For example, some websites take input in JSON or XML format and use this to query the database. These different formats may provide different ways for you to obfuscate attacks that are otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often look for common SQL injection keywords within the request, so you may be able to bypass these filters by encoding or escaping characters in the prohibited keywords. For example, the following XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT: 123 999 SELECT * FROM information_schema.tables This will be decoded server-side before being passed to the SQL interpreter.  SQL injection examples There are lots of SQL injection vulnerabilities, attacks, and techniques, that occur in different situations. Some common SQL injection examples include: 1. Retrieving hidden data: where you can modify a SQL query to return additional results. 2. Subverting application logic: where you can change a query to interfere with the application's logic. 3. Retrieving data from other tables: In cases where the application responds with the results of a SQL query, an attacker can use a SQL injection vulnerability to retrieve data from other tables within the database. You can use the UNION keyword to execute an additional SELECT query and append the results to the original query. 4. Blind SQL injection: where the results of a query you control are not returned in the application's responses.  SQL injection examples 5. Second-order SQL injection: First-order SQL injection occurs when the application processes user input from an HTTP request and incorporates the input into a SQL query in an unsafe way. Second-order SQL injection occurs when the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability occurs at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into a SQL query in an unsafe way. For this reason, second-order SQL injection is also known as stored SQL injection 6. Examining the database: Some core features of the SQL language are implemented in the same way across popular database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities work identically on different types of database. However, there are also many differences between common databases. These mean that some techniques for detecting and exploiting SQL injection work differently on different platforms.  Examining the database  Querying the type and version You can potentially identify both the database type and version by injecting provider-specific queries to see if one works The following are some queries to determine the database version for some popular database types: Database type Query Microsoft, MySQL SELECT @@version Oracle SELECT * FROM v$version PostgreSQL SELECT version()  Listing the contents Most database types (except Oracle) have a set of views called the information schema. This provides information about the database. For example, you can query information_schema.tables to list the tables in the database: SELECT * FROM information_schema.tables  UNION attacks When an application is vulnerable to SQL injection, and the results of the query are returned within the application's responses, you can use the UNION keyword to retrieve data from other tables within the database. This is commonly known as a SQL injection UNION attack. The UNION keyword enables you to execute one or more additional SELECT queries and append the results to the original query. For example: SELECT a, b FROM table1 UNION SELECT c, d FROM table2 This SQL query returns a single result set with two columns, containing values from columns a and b in table1 and columns c and d in table2. For a UNION query to work, two key requirements must be met: 1. The individual queries must return the same number of columns. 2. The data types in each column must be compatible between the individual queries. To carry out a SQL injection UNION attack, make sure that your attack meets these two requirements. This normally involves finding out:  How many columns are being returned from the original query.  Which columns returned from the original query are of a suitable data type to hold the results from the injected query.  How many columns are being returned from the original query? When you perform a SQL injection UNION attack, there are two effective methods to determine how many columns are being returned from the original query. 1. One method involves injecting a series of ORDER BY clauses and incrementing the specified column index until an error occurs. ' ORDER BY 1-- ' ORDER BY 2-- ' ORDER BY 3-- etc. 2. The second method involves submitting a series of UNION SELECT payloads specifying a different number of null values: ' UNION SELECT NULL-- ' UNION SELECT NULL,NULL-- ' UNION SELECT NULL,NULL,NULL-- etc.  Which columns returned from the original query are of a suitable data type to hold the results from the injected query? A SQL injection UNION attack enables you to retrieve the results from an injected query. The interesting data that you want to retrieve is normally in string form. This means you need to find one or more columns in the original query results whose data type is, or is compatible with, string data. After you determine the number of required columns, you can probe each column to test whether it can hold string data. You can submit a series of UNION SELECT payloads that place a string value into each column in turn. For example, if the query returns four columns, you would submit: ' UNION SELECT 'a',NULL,NULL,NULL-- ' UNION SELECT NULL,'a',NULL,NULL-- ' UNION SELECT NULL,NULL,'a',NULL-- ' UNION SELECT NULL,NULL,NULL,'a'--  How to prevent SQL injection You can prevent most instances of SQL injection using parameterized queries instead of string concatenation within the query. These parameterized queries are also know as "prepared statements". The following code is vulnerable to SQL injection because the user input is concatenated directly into the query: String query = "SELECT * FROM products WHERE category = '"+ input + "'"; Statement statement = connection.createStatement(); ResultSet resultSet = statement.executeQuery(query); You can rewrite this code in a way that prevents the user input from interfering with the query structure: PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?"); statement.setString(1, input); ResultSet resultSet = statement.executeQuery(); Application functionality that places untrusted data into these parts of the query needs to take a different approach, such as: Whitelisting permitted input values. Using different logic to deliver the required behavior.  ASSIGNMENT  EXPLAIN WITH DETAILS : 1. Whitelisting permitted input values. 2. Using different logic to deliver the required behavior. “ HTTPS ”  ?What are SSL and TLS SSL – Secure Socket Layer TLS – Transport Layer Security Both provide a secure transport connection between applications (e.g., a web server and a browser) SSL was developed by Netscape SSL version 3.0 has been implemented in many web browsers (e.g., Netscape Navigator and MS Internet Explorer) and web servers and widely used on the Internet SSL v3.0 was specified in an Internet Draft (1996) It evolved into TLS specified in RFC 2246 TLS can be viewed as SSL v3.1 SSL components  Four Protocols 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol Handshake Protocol HANDSHAKE PROTOCOL : Phase 1 HANDSHAKE PROTOCOL : Phase 1  After Phase I, the client and server know the following: 1. The version of SSL 2. The algorithms for key exchange, message authentication, and encryption 3. The compression method 4. The two random numbers for key generation HANDSHAKE PROTOCOL : Phase 2 HANDSHAKE PROTOCOL : Phase 2  After Phase II, 1. The server is authenticated to the client. 2. The client knows the public key of the server if required. HANDSHAKE PROTOCOL : Phase 3 HANDSHAKE PROTOCOL : Phase 3  After Phase III, 1. The client is authenticated for the server. 2. Both the client and the server know the pre-master secret. HANDSHAKE PROTOCOL : Phase 4 HANDSHAKE PROTOCOL : Phase 4  After Phase IV,.Client and server are ready to exchange data Record Protocol  SSL Record Protocol 1. Fragmentation 2. Compression 3. Message Authentication And Integrity Protection 4. Encryption Record Protocol Alert protocol  SSL Alert Protocol error messages (fatal alerts and warnings)  Change Cipher Spec Protocol  SSL Change Cipher Spec Protocol A single message that indicates the end of the SSL handshake  ASSIGNMENT  What are the differences between TLS and SSL?  HTTPS and the Lock Icon Intended goal: Provide user with identity of page origin Indicate to user that page contents were not viewed or modified by a network attacker All elements on the page fetched using HTTPS: HTTPS cert issued by a CA trusted by browser HTTPS cert is valid (e.g. not expired) Domain in URL matches: CommonName or SubjectAlternativeName in cert “ AUTHENTICATION ”  ?What is authentication  Idea: Verify the user is who they say they are  Authentication systems classically use three factors: Something you know (e.g. a password) Something you have (e.g. a phone, badge, or cryptographic key) Something you are (e.g. a fingerprint or other biometric data) The more factors used, the more sure we are that the user is who they say they are  Authentication vs. Authorization  Authentication: Verify the user is who they say they are Login form Ambient authority (e.g. HTTP cookies) HTTP authentication  Authorization: Decide if a user has permission to access a resource Access control lists (ACLs) Capability URLs  Network-based guessing attacks Three primary types of attack : Brute force: Testing multiple passwords from dictionary or other source against a single account. Credential stuffing: Testing username/password pairs obtained from the breach of another site Password spraying: Testing a single weak password against a large number of different accounts Network-based guessing defenses Limit the rate at which an attacker can make authentication attempts, or delay incorrect attempts Keep track of IP addresses and limit the number of unsuccessful attempts Temporarily ban the user after too many unsuccessful attempts CAPTCHA