comp344ass2 - Diagr am - Account Det ails For m Macquarie...

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Diagr am - Account Det ails For m Macquarie University COMP 344 - Assignment 2 Online Store Security Aspects Matt Brunsdon (41226607) Overview This document is an investigation of security issues in the online store web application developed in assignment one for COMP344 * ; with a specific focus on the issues outlined in the Open Web Application Security Project (OWASP) Top 10 Most Critical Web Application Security Risks for 2010. The format for this document will be: an outline of each security issue followed by a short technical explanation of the issue then an investigation of how the issue affects the online store application. * http: / /spider.ics.mq.edu.au / ics /s4122660 /default.asp Investigation 1. I njection What is injection? Injection flaws occur when un-t rusted data is sent to an interpreter as part of a command query, the data can be used to execute unintended commands using the applications resources. An example of this technique is sending SQL syntax to the application via a HTTP parameter that is then executed on the database directly. To prevent this issue validation for SQL syntax of all data being transmitted from the client to the server must be performed. Does it affect the Online Store? Yes, Looking at the Online Store application, most of the SQL syntax it built using un-validated HTTP GET and POST parameters. In total there are 17 locations in the Default.asp file that build SQL statements dynamically using these un-validated variables. The process for these handlers to be t riggered as outlined in Diagram 1 is: the application is sent an action parameter via HTTP GET or POST that corresponds with the action for this handler; the SQL is then built using the other passed parameters and executed. Diagram - Delete Order I tem Code Execution Sequence An example of an injection attack possible using the current application architecture as displayed in Diagram 2 is: the browser sends a delete order item request to the application however the orderId parameter is actually SQL that closes the intended query using a comma and semicolon then executes additional SQL on the application causing unintended results. For this sequence to be satisfied, the victim must be logged into the application or the attacker must execute the code from their own authenticated session. NT: Diagram 2 shows the interpreted SQL. Diagram - Delete Order I tem SQL I njection Attack Sequence To avoid this issue from occurring an input validation function must be created that checks for SQL syntax, this single function will be used to check all information provided by HTTP GET & POST variables. An example of such a function is shown in Diagram 3 . Diagram - Function used to validate input for SQL Characters 2. Cross Site Scripting (XSS) What is Cross Site Scripting?...
View Full Document

Page1 / 28

comp344ass2 - Diagr am - Account Det ails For m Macquarie...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online