Li - Web App Testing - 2014.pdf - RomiSatriaWahono.Net

Introduction

Motivation, challenges and overview of techniques

• Interoperability
• Security
• Dynamics
• Overview of techniques

User session-based testing [36,9] ✓ Test the web application by collecting a list of user sessions and replaying them. Scanning and crawling uncleaned user input to crash the web application (for example, the database or force the user to visit unsafe websites).

Graph- and model-based white-box testing techniques

Graph-based testing

One of the aspects of web application testing that we do not cover in this study is usability testing [18]. Generally speaking, such a usability test in the case of web applications will involve testing e.g. (1) the ease of use of the application, (2) the layout and appearance of the web application on various devices such as desktops, laptops and mobile systems, and (3) whether various messages displayed during the application are sufficient and appropriate.

Finite state machine testing

Logical Web Pages (LWP) can be easily extracted because they are embedded with HTML "Form" tags. For input values ​​[20] defines five broad choices, namely R (if input is required, i.e. the user must enter a value to transition from one state to another), Rðparm¼valueÞ (if input is required and can only be selected from a subset for transition from one state to another), O (if the input is optional), C1 (if the user only needs to select a tone input from a given list of inputs, e.g. radio button) and Cn (if the user needs to select several values ​​from the list, e.g. confirmation fields).

Probable FSM

Assuming the threshold value was set to 0.1, only paths A and B will be selected as test cases for the test suite. Thus, the threshold value can be modified to control the number of generated test cases and its coverage.

Mutation testing

A high threshold can be selected to test only the most commonly used operations, and it can be gradually lowered to include the rarer and more unique operations and ensure satisfactory coverage or reliability for a wider variety of operations. The limitation of this work is that the probable FSM cannot be generated automatically and thus the testing process will be slow because the FSM construction has to be performed manually.

Search based software engineering (SBSE) testing

The lower the absolute value of offset1, i.e. the closer the value of offsetis to 1, the closer the test case is to traversing the correct target branch [48]. The fitness function has a value of 0 if the test case covers the desired branch of the program.

Scanning and crawling techniques

XSS and SQL injection detection techniques

Web applications usually read user data, which is then sent to the server for processing. Messages posted by users are sent to a CGI (Common Gateway Interface) program that inserts them into the web application's database. When a user sends a request to view posted messages, the CGI program retrieves the messages from the database, generates a response page, which is then sent to the web browser used by the web application client.

In this scenario, even though the executed script was written by a malicious hacker, it was delivered to the browser on behalf of the web application. Such scripts can therefore be used to read a web application's cookies and break its security mechanisms. The data generated by the IKM is then passed on by the spider to the web application to detect further backends ie. deep site discovery.

Black-box Web vulnerability scanners

Another key finding from Bau et al. highlights that most scanners were effective at detecting type 1 or simpler XSS vulnerabilities (where no invalid data is written to the database), for example the average percentage of. The scanners were also poor at detecting 'stored' vulnerabilities (for example, the detection rate of 'stored XSS' was roughly 15%, and no scanner could detect second-order SQL injection vulnerabilities)[25]. For stored XSS vulnerabilities, unsanitized user input is written directly to the database and the test cases are then tested by reading unsanitized values ​​from the database.

For each form, SecuBat automatically outputs the address mentioned in the forms action field (ie, the address to which the cleared entries are sent) along with the method field (ie, GETorPOST). Usually, the confidence value is chosen in such a way that false positives (ie, the attack is actually not successful, but the confidence value indicates otherwise) are reduced. The Aqueue controller periodically checks the crawl queue for new tasks which are then sent to the thread controller.

Crawling and testing AJAX applications

Unit testing tools such as JsUnit can be used to test JavaScript at a functional level. Another challenge includes the fact that faulty inputs in AJAX applications can be triggered by various UI events. Once the state changes are detected, a state flow graph is created, which includes the states of the user interface and the (event-based) transitions that may exist between them.

The dead links/clickable links can be detected by listening to the client/server request/response traffic after each event. Consistent back button: This is one of the more common problems in AJAX web applications (the existence of a broken back button in the browser). By crawling, a comparison can be made between the expected state in the graph with the state after executing the back button and inconsistencies or errors can be detected automatically.

Random testing and assertion-based testing of Web services

• Jambition: random testing to Web service
• Testing Web services choreography through assertions
• Artemis: a feedback-directed random testing framework for JavaScript applications
• JSContest: contract-driven random testing of JavaScript

Also, in AJAX, responses to each client-side event are injected into the single-page interface, and errors are propagated to the DOM level. In the following two subsections, we discuss the application of random testing and assertion-based testing to Web services. These constraints are then solved to generate new input data, and further constraints are then created in the next simulation.

The testing process ends when all branches in the choreography have been traversed by the simulation engine. When the assertion is satisfied for all paths in the program, then the assertion is proved to be true for the service choreographies. The coverage-based strategy prioritizes sequences of events based on the coverage product of all events in the sequence.

Fig. 8. A diagram showing the testing approach for a WS-CDL program as described in [27, Fig

Fuzz testing

White-box fuzz testing

The actual effectiveness of white-box fuzzing is limited when testing applications with highly structured inputs, such as compilers and interpreters. Due to the large number of control paths in the early stages of processing, white-box fuzzing, in the presence of a well-formed data set, rarely goes beyond these initial stages of input processing. 33], which improves white-box fuzzing when applying it to complex structured input applications with a grammar-based specification of valid inputs.

The results of these experiments show that grammar-based white-box fuzzing explores deeper programming paths and avoids dead ends due to unparsable inputs. Compared to conventional white-box fuzzing, grammar-based fuzzing increased the code generation module coverage of the IE7 JavaScript interpreter from 53% to 81% while using three times fewer tests [33]. By limiting the search space to valid entries, grammar-based fuzzing can perform deeper paths and focus the search on deeper levels of processing that are more difficult to test.

FLAX: a black-box fuzz testing framework for JavaScript

The collected constraints are then dened one by one and solved with a constraint solver, which provides new inputs that enable the exploration of different control paths in the program. This allows additional code to be exercised and tested for security flaws, even without specific knowledge of the input format. This algorithm is implemented in the Microsoft white-box testing tool SAGE (Scalable, Automated, Guided Execution)[31], which is a tool that uses x86 instruction-level tracing and emulation for white-box obfuscation of arbitrary file-reading Windows applications.

Another approach to solve the limited coverage problem due to white-box fuzz testing is proposed by Godefroid et al. A new dynamic test generation algorithm is proposed where symbolic execution directly generates grammar-based constraints whose satisfiability is checked using a grammar-based constraint solver. Moreover, the grammar-based constraint solver can satisfy a partial set of token constraints on a fully defined valid input, thus avoiding the exploration of many possible nonparalyzable completions.

Concolic Web application testing

• Concrete, symbolic execution
• A string-based concolic testing approach for PHP applications
• Apollo: a path-based concolic testing framework for PHP applications
• Minimisation of path constraints
• Implementation technique
• Kudzu: a symbolic testing framework for JavaScript

New test input is then created by solving modified versions of the obtained path constraint. To obtain the different modified versions of the path constraint, the last constraint in the original path constraint is removed and the last conjunction in the new path constraint is negated. Similarly, these constraints are solved by the constraint solver that allows exploring different paths of program execution.

To do this, for a given defect report, the intersection of the various path constraints that expose a fault is taken. Iteratively, each constraint from the intersection of the path constraints is removed one by one. Similarly, the Bug Finder uses an oracle to find HTML errors, keeps track of the various bug reports and minimizes the path constraints responsible for a particular error.

Fig. 11. An example PHP program from [35, Fig. 1] that contains an SQL injection vulnerability.

User session-based testing

• Test case prioritisation and reduction for user session-based testing
• Batch test suite reduction
• Incremental reduced test suite update
• Test case reduction through examining URL trace

In terms of user session-based testing, setOrepresents the set of user sessions (ie, the number of test cases). and array A represents URLs for user sessions. The different user sessions are shown in Table 1. The objects are represented in rows, where the prefix "G" indicates GET requests and the prefix "P" indicates POST requests), both of which prefix different attributes A (columns of Table 1). After each addition of a user session, the concept latticeL0 is updated, and if a user session Sire places the side-down node in the lattice (ie, the nodes that are connected to the bottom element ?), Sii is then added to the bundle of updated to testT0 and the session replaced by the next end node representing the user is removed from the test set T0.

However, if a user session Si does not replace a node next to the bottom one in the grid, the test suite is not changed and the user session (i.e. the test case) is ignored. The remaining test suites are prioritized based on their descending length of their largest common prefixes, i.e. the test suite with the longest largest common prefix is ​​executed, then the one with the second longest largest common prefix, and so on. In each test suite, the test cases are prioritized based on the coverage ratios of the requested URLs, that is, the test case with a longer URL trace is executed sooner.

Fig. 15. A graphical representation of a lattice construction from the different objects and attributes given in Table 4

Conclusion and future directions

Another limitation of the Finite State Machine (FSM-based) testing technique is that it has limited support for unanticipated, user-controlled transitions, called operational transitions [81]. Jovanovic, SecuBat: a web vulnerability scanner, in: Proceedings of the 15th International Conference on World Wide Web, WWW '06, ACM, New York, NY, USA, 2006, pp. of web applications through concept analysis, in: Proceedings of the 19th International Conference on Automated Software Engineering, 2004, pp.

Proceedings of the 23rd International Conference on Software Engineering, ICSE'01, IEEE Computer Society, Washington, DC, USA, 2001, s. Tip, A framework for automated test of JavaScript web applications, in: Proceedings of the 33rd International Conference om Software Engineering, ICSE'11, ACM, New York, NY, USA, 2011, s. Thiemann, Kontraktdrevet test af JavaScript-kode, i: Proceedings of the 48th International Conference on Objects, Models, Components, Patterns, TOOLS' 10, Springer-Verlag, Berlin, Heidelberg, 2010, pp.