WEB APPs
difference between a session and a session token
A session is a set of data structures held on the serverthat are used to track the state of the user's interaction with the application[1]. A session token is a unique string that the application maps to the session, and is submitted by the user to reidentify themselves across successive requests[1]
Attempting to prevent all categories of attack simultaneously at the application's external boundary may sometimes be impossible.Discuss why this is the case and what can be done to mitigate this problem.
A typical application needs to defend itself against a huge variety of input-based attacks[1]. Many application functions involve chaining together a series of different types of processing[1]. A single piece of user-suppliedinput might result in a number of operations in different components, with the output of each being used as the input for the next[1].As the data is transformed, it might come to bear no resemblance to the original input, and a skilled attacker may be able to manipulate the application to cause malicious input to be generatedat a key stage of the processing, attacking the component which receives this data[1].Defending against different categories of input-based attack may entail performing differentvalidation checks on user input that are incompatible with one another[1].A more effective model uses the concept of boundary validation [1].Here, each individual component or functional unit of the server-side application treats its inputs as coming from a potentially malicious source[1]. Data validation is performed at each of these trust boundaries, in addition to the external frontier between the client and server[1].Because the various validation checks are implemented at different stages of processing, they are unlikely to come into conflict with one another[1]
A login mechanism involves the following steps:a.The application requests the user's username and passcode.b.The application requests two randomly chosen letters from the user's memorable word. Why is the required information requested in two separate steps? What defect would the mechanism contain if this were not the case?
Even if an attacker captures all of the credentials supplied by a user in a single login, it is unlikely that the attacker will be able to repeat the login using those credentials, because a different pair of letters will be requested [1].If all of the required information is requested in a single step, then it must select the randomly chosen letters in advance, without knowing the claimed identity of the authenticating user [1]. This means that an attacker who knows only two letters from a user's memorable word can simply reload the login form repeatedly until those two letters are requested, enabling them to log in using the captured credentials [1].To avoid this defect, the application must choose a new pair of letters following each successful login [1], and store these in the user's profile until such time as the user successfully logs in again [1]. When the user has identified themselves at stage one of the login, the pair of letters is retrieved from their profile, and requested from the user [1]. In this way, an attacker who has captured the credentials in a single login will typically need to wait a very long period until the items are re-requested by the application [1]
three security mechanisms for handling user accesson web applications.
In a typical application, access is handled using a trio of mechanisms relating to authentication, session management, and access control[1].Authenticationinvolves establishing that the user is in fact who he claims to be[1]. Adefective authentication mechanism may enable an attacker to login as any user and so gain unauthorised access[1]. Webapplications create a session for each user and issue the user a token that identifies the session [1]. If sessiontokens can be predicted, an attacker may be able to masquerade as any logged in user and gain access to their data[1]. Access control concerns whether the user is authorised to perform the action, or access the data, that he is requesting[1]. If access controlsare broken, then any user may be able to directly use functionality that is supposed to be protected[1].These components are highly interdependent, and a weakness in any one of them will undermine the effectiveness of the overall access handling mechanism[1]
You want to use the UNIONstatement to extract the database version (you can assume the statement @@version to return this). Explain, why knowing the number of columns and data type is important in this context. Showand describe how to test for the number of columns in an SQL statement.Detail how to return the version of the database
Knowing the number of columns is important because two queries can only be joined together using UNIONif they match in number of columns and data types [1]. Therefore the second query that is joined by UNIONmust return the same number of columns as the first one implemented by the web application [1].NULL can be implicitly converted to any data type [1].7Therefore systematically inject queries with an increasing number of NULLs [1]. If the number of columns in both queries don't match, the query will either return an error or no data (if the error is suppressed by the application) [1].If the query is executed you see the data returned by the first query.Payload [1]: ' UNION SELECT NULL --' UNION SELECT NULL, NULL --' UNION SELECT NULL, NULL, NULL --Alternatively you can also addORDER BY 1(and then 2, 3, etc.) to the query. Starting with thelowest value an error should occur when the number of columns is exceeded [1].In order to read data we need to identify a column that can return string data [1].Move a string literal, e.g. 'x' along the columns. The column used for the string literal when it is successfully returned can be used to return string data [1].' UNION SELECT 'x', NULL, NULL --' UNION SELECT NULL, 'x', NULL --[1]NB: statements can also include FROM DUAL if Oracle DB is assumed (@@version is SQLS but the focus of this question is on the testing, not db).
Explain, what an SQL Injection vulnerability is. In your answer include what makes an SQL Injection possible on the system.
SQL Injection is an insertion (injection) of either a partial or complete SQL query [1] via user-controlled data input transmitted from the client to the web application [1], that is not properly controlled by the application [1] and is used to build (complete) an SQL statement [1] that is then executed in an interpreted context (the database) [1]. Executing such a statementcan read sensitive data from the database[1], modify database data (insert/update/delete)[1]or execute administration operations [1]. It is enabled by passing user supplied input un-sanitized into a query that that is then executed in a different, interpreted context, the database[1]. It is better to use parameterized queries and supply user input into those[1]. User input should also be sanitised [1]
How can self-registration functions introduce username enumeration vulnerabilities? How can these vulnerabilities be prevented?
Self-registration functions are often vulnerable to username enumeration because users can choose their own username and the application prevents them from registering an existing username [1]. Therefore an attacker can discover existing usernames as these would be rejected 5during registration [1].Applications can avoid self-registration functionality being misused in this way through two methods:The application can generate its own usernames, assigning a non-predictable [1]username to each new user when they have supplied the required personal information [1].The first step of the self-registration process can require users to enter their email address. The application then sends the user an email containing a one-time URL that they can use to continue the registration process[1]. If the supplied email address is already registered, the user is notified of this in the email [1
As part of an SQL Injection attack explainhow the UNION operator can be used to extract further information from the database. In your answer address the purpose and constraints of the SQL UNION operator, and how it is used to extract additional data from a database.
The SQL UNION operator joins the results of two queries together [1]. In the context of an SQL Injection attack the UNION operator is used to add an arbitrary query to an existing query when the user input is a parameter in the WHERE clause [1].If query results are returned directly to the browser, this strategy can be used to extract arbitrary data from the database (i.e. data that is not part of the 'original' query) [1].The two result sets must have the same structure[1]. In other words, they must contain the same number of columns, which have the same or compatible data types, appearing in the same order[1].The attacker would needto know the name of the database table that he wants to target[1], and the names of its relevant columns[1].
the difference between a reflectedand a storedcross-site scripting attack.
The answer should outline each type of attack. In a reflected XSS attack the application embeds the usersupplied input parameter in the HTML page sent back to the user[1], e.g. a search string is "reflected" in the response (page), without sanitising the input. As a result malicious HTML and/or JavaScript will be processed by the victim's browser[1]. Stored XSS occurs when a web application stores the malicious user input (typically in a database) supplied by a hacker[1]. The input is then displayed back without being sanitised to any other user that views this hacker's supplied content. As a result themalicious data will be "downloaded" and processed in the victim's browser[1].The difference is that with a reflected XSS attack the attacker must get the victim to visit his malicious URL whereas in a stored XSS attack (once the malicious code has beenstored) the victim on his own accord will simply browse the hacker supplied content as part of the application[1].XSS attacks are often used to steal session tokens, so the victim needs to be logged into the application to exploit the vulnerability[1]. This would naturally be the case when the user browses the contentas s/he would be during a stored XSS attack. The user isn't necessarily logged in during a reflected XSS attack (although the hacker may try to tempt the victim)[1]. Therefore a storedXSS attack is the more serious type of XSS attack[1].
While testing a web application, you log in using your credentials of joeand pass. During the login process, you see a request for the following URL appear in your intercepting proxy: http://www.example.com/app?action=login&uname=joe&password=passDescribe thevulnerabilities can you diagnose without needing to probe any further?
The credentials are transmitted within the query string of the URL [1]. These are at risk of unauthorised disclosure via the browser history, the logs of the web server and IDS, or simply by appearing on-screen [1].The credentials are transmitted via an unencrypted HTTP connection [1], making them vulnerable to interception by an attacker who is suitably positioned on the network [1].The password is an English word consisting of four lowercase alphabetical characters [1]. The application is not enforcing any effective password quality rules [1]
In the context of client-side controls, how can data be transmitted via the client in a way that prevents tampering attacks?
The data can be encrypted or hashed using a key stored on the server, as is optionally done for the ASP.NET ViewState [1]. Unless an attacker somehow captures the key, they will be unable to encrypt arbitrary data or compute a valid hash for arbitrary data [1]. However, the attacker may still be able to take data from one context and replay it in another [1] -for example, theencrypted price for a cheap item could be submitted in place of the encrypted price for an expensive item [1]. To prevent this attack, the application should include sufficient context within the protected data to be able to confirm that it originated inthe same context as it is being employed [1] -for example, the product code and price could be combined in a single encrypted blob [1].
the purpose of a web admin page and why is it especially important to secure
Web apps needto providea way for administrators to manage user accounts and roles, access monitoring and audit functions, perform diagnostic tasks, and configure aspects of the application's functionality[1].In many apps, admin functions are part of the app itself, accessible through the same web interface[1].Weaknesses in authentication may enable an attacker to gain admin access, effectively compromising the entire application[1].Admin functionality is often subjected to less rigorous security testing, because its users are deemed to be trusted[1].It often has a need to perform inherently dangerous operations, involving access to files on disk or operating system commands[1]
Why is it not always possible to use a whitelist-based approach to input validation
here are many situations where an application may be forced to accept data for processing that does not match a list or pattern of input that is known to be "good" [1]. For example, many people's names contain characters that can be used in various attacks [1]. If an application wishes to allow people to register under their real names, it needs to accept input that may be malicious, and ensure that this is handled and processed in a safe manner nevertheless [1]
