My Texts

Security Testing from Agile Perspective.

Security testing from perspective of scrum development Rudra Prasad Tripathy Ph. D. scholar, Utkal university Technical architect, JDA india software(P) Ltd. Hyderabad,lndia Rudral [email protected] com RanJit Kumar Panda Senior Engineer, MindTree Limited Bangalore, India Abstract” We are trying to show how security testing plays predominant role in secured development and through agile methodology-particularly scrum is a suitable development process. Keywords-scrum;security testing. 1. Introduction Application security is in attention for last few years where security no more allures to network security and transcen.

Security testing is also crux of secured development though it’s not getting its due importance. In this paper we would discuss issues involved in security testing in traditional software development lifecycle approach like waterfall and would compare with scrum methodology, which is a agile methodology to see how it would smoothen few issues and would facilitate security testing. We would take cross-side scripting as the example to illustrate the study. 1 . 1 What is security testing? Application security would basically deals with the situation to try to break the software as what an attacker would do.

This is different from traditional testing because of following idiosyncratic features. a. Traditional testing doesn’t deal with what happens if it fails, where as security testing objective to break the system and would play a role of antagonist. Hence it requires dexterity and experience to draw suitable test cases apart from tools and frameworks.. b. This would be part of risk management and hence need to reckon the cost involved. We may need to define adequate security [1] parlance to application’s business domain and value proposition aimed at.

For example definition of adequate security a online credit card pplication and online healthcare system would differ. Hence prioritization and budgeting of resources are few factors need to be considered. c. Testing of different possible vulnerabilities [2]. 1. 2Security testing approaches. Currently application security testing has been done as a white box testing, may be with help of few tools like static analysis tools to study the vulnerability. Apart from that non functional testing has been conducted to see chance of failures against vicarious attack of adversary. 1. Cross-Site Scripting Cross-site Scripting (XSS) vulnerabilities were verified as executing code on the web uch as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. XSS can generally be subdivided into two categories-stored and reflected attacks. Stored attacks are something like form stored on the target server, such as in a database, or via a submission to a bulletin board or visitor log. Reflected attacks, on the other hand, come from somewhere else.

This happens when user input from a web client is immediately included via server-side cripts in a dynamically generated web page. Insufficient filtering of client-supplied data that is returned to web users by the web application is the major cause. In many cases, the client-supplied data is being used in the HTTP headers, which could be exploited by using carriage return-linefeed sequence-an attacker can add HTTP headers to the response and completely write the body of the HTTP request. 2. MOTIVATION In one of the web application, an XSS was found through use of third party tool.

This was a critical defect. Design had been made and after implementation code had een tested by security compliance team. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. A full security review usually involves more than Just seeking out XSS vulnerabilities. it also involves overall threat modeling, testing for different threats like overflows, information disclosure, error handling, SQL injection, authentication, and authorization bugs. The nice thing is that doing a thorough Job in any one area often overlaps with another.

Like, while testing for XSS vulnerabilities, you will very ften identify error handling and information disclosure problems as well. Though automated tool like webinspect were available, we did some manual testing through a tool called Paros [8] for HTTP traffic interception. Intercepting the client GET and POST requests is extremely important. One could circumvent any sort of client-side JavaScript input validation code that may have been pushed down. A simple test will be changing a get parameter in the request. Let the URL is as below http:// www. yoursite. com/index. html? param=test. One would modify the URL like http://www. oursite. com/index. tml? name=alert(‘XSS’), and subsequently, if a popup opens up saying XSS then this parameter is open to XSS vulnerable. Paros Proxy is used to intercept the request parameter. Using this tool we will inject some malicious Javascript code into the cookies, header or form parameters. If the code will be executed while the response is displayed in the browser, the application is vulnerable to XSS. 2. 1 Security testing models There are many methodologies proposed

Leave a Reply
