2nd USENIX Conference on Web Application Development ...

More documents

Recommendations

Info

[5] The spring framework. http://www.springsource. org/, 2011. [6] DUCASSE, S., LIENHARD, A., AND RENGGLI, L. Seaside: A flexible environment for building dynamic web applications. IEEE Softw. 24 (September 2007), 56–63. [7] EVANS. Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [8] FIELDING, R., GETTYS, J., MOGUL, J., FRYSTYK, H., MAS- INTER, L., LEACH, P., AND BERNERS-LEE, T. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard), June 1999. Updated by RFC 2817. [9] KRASNER, G., AND POPE, S. A cookbook for using the modelview controller user interface paradigm in smalltalk-80. J. Object Oriented Program. 1, 3 (1988), 26–49. [10] LEFF, A., AND RAYFIELD, J. T. Web-application development using the model/view/controller design pattern. Enterprise Distributed Object Computing <strong>Conference</strong>, IEEE International 0 (2001), 0118. [11] MIKKONEN, T., AND TAIVALSAARI, A. Web applications ? spaghetti code for the 21st century. Software Engineering Research, Management and Applications, ACIS International <strong>Conference</strong> on 0 (2008), 319–328. [12] MORALES-CHAPARRO, R., L. M. P. J. C., AND SÁNCHEZ- FIGUEROA, F. Mvc web design patterns and rich internet applications. In Proceedings of the <strong>Conference</strong> on Engineering Software and Databases (2007). [13] QUEINNEC, C. Continuations and web servers. Higher Order Symbol. Comput. 17 (December 2004), 277–295. [14] RICHARDSON, L., AND RUBY, S. RESTful Web Services. O’Reilly, 2007. [15] RUDERMAN, J. The same origin policy, 2001. [16] SOUDERS, S. High performance web sites, first ed. O’Reilly, 2007. [17] SOUDERS, S. Even Faster Web Sites: Performance Best Practices for Web Developers, 1st ed. O’Reilly Media, Inc., 2009. 98 WebApps ’11: <strong>2nd</strong> <strong>USENIX</strong> <strong>Conference</strong> on Web Application Development <strong>USENIX</strong> Association
Abstract Exploring the Relationship Between Web Application Development Tools and Security Matthew Finifter University of California, Berkeley finifter@cs.berkeley.edu How should software engineers choose which tools to use to develop secure web applications? Different developers have different opinions regarding which language, framework, or vulnerability-finding tool tends to yield more secure software than another; some believe that there is no difference at all between such tools. This paper adds quantitative data to the discussion and debate. We use manual source code review and an automated black-box penetration testing tool to find security vulnerabilities in 9 implementations of the same web application in 3 different programming languages. We explore the relationship between programming languages and number of vulnerabilities, and between framework support for security concerns and the number of vulnerabilities. We also compare the vulnerabilities found by manual source code review and automated black-box penetration testing. Our findings are: (1) we do not find a relationship between choice of programming language and application security, (2) automatic framework protection mechanisms, such as for CSRF and session management, appear to be effective at precluding vulnerabilities, while manual protection mechanisms provide little value, and (3) manual source code review is more effective than automated black-box testing, but testing is complementary. 1 Introduction The web has become the dominant platform for new software applications. As a result, new web applications are being developed all the time, causing the security of such applications to become increasingly important. Web applications manage users’ personal, confidential, and financial data. Vulnerabilities in web applications can prove costly for organizations; costs may include direct financial losses, increases in required technical support, and tarnished image and brand. David Wagner University of California, Berkeley daw@cs.berkeley.edu Security strategies of an organization often include developing processes and choosing tools that reduce the number of vulnerabilities present in live web applications. These software security measures are generally focused on some combination of (1) building secure software, and (2) finding and fixing security vulnerabilities in software after it has been built. How should managers and developers in charge of these tasks decide which tools – languages, frameworks, debuggers, etc. – to use to accomplish these goals? What basis of comparison do they have for choosing one tool over another? Common considerations for choosing (e.g.,) one programming language over another include: • How familiar staff developers are with the language. • If new developers are going to be hired, the current state of the market for developers with knowledge of the language. • Interoperability with and re-usability of existing inhouse and externally-developed components. • Perceptions of security, scalability, reliability, and maintainability of applications developed using that language. Similar considerations exist for deciding which web application development framework to use and which process to use for finding vulnerabilities. This work begins an inquiry into how to improve one part of the last of these criteria: the basis for evaluating a tool’s inclination (or disinclination) to contribute to application security. Past research and experience reveal that different tools can have different effects on application security. The software engineering and software development communities have seen that an effective way to preclude buffer overflow vulnerabilities when developing a new application is to simply use a language that offers automatic memory management. We have seen also that even if other requirements dictate that the C language must be used for development, using the safer strlcpy instead <strong>USENIX</strong> Association WebApps ’11: <strong>2nd</strong> <strong>USENIX</strong> <strong>Conference</strong> on Web Application Development 99
Page 1 and 2:
Proceedings of the 2nd</str
Page 3 and 4:
USENIX Association
Page 5:
WebApps ’11: 2nd
Page 9 and 10:
GuardRails: A Data-Centric Web Appl
Page 11 and 12:
Policy Annotation Only admins can d
Page 13 and 14:
@edit, price, false, :nothing To ma
Page 15 and 16:
tags in the Project description, bu
Page 17 and 18:
String Command Result "foobar".gsub
Page 19 and 20:
Transformation Status Homepage Logi
Page 21 and 22:
Abstract Ioannis Papagiannis Imperi
Page 23 and 24:
Num. of Occurrences Type Wordpress
Page 25 and 26:
Sanitisation htmlentities() functio
Page 27 and 28:
Original expression Transformed exp
Page 29 and 30:
non-tracking code with a simple str
Page 31 and 32:
Direct request vulnerabilities. The
Page 33 and 34:
Abstract Secure Data Preservers for
Page 35 and 36:
e found for a variety of services.
Page 37 and 38:
3.2 Operational View The lifecycle
Page 39 and 40:
it automatically). A user or servic
Page 41 and 42:
given the availability of client-si
Page 43 and 44:
can only be decrypted by the base l
Page 45 and 46:
BenchLab: An Open Testbed for Reali
Page 47 and 48:
2.2. Realistic load generation Real
Page 49 and 50:
virtual machine with the software s
Page 51 and 52:
the Olio calendaring applications (
Page 53 and 54:
able to match Firefox’s optimized
Page 55 and 56: 5.4.1. Local vs remote users We obs
Page 57 and 58: Resource Provisioning of Web Applic
Page 59 and 60: in a directed acyclic graph [3]. Th
Page 61 and 62: accordingly. This is the goal of in
Page 63 and 64: Although expressing performance pro
Page 65 and 66: Response time (ms) Response time (m
Page 67 and 68: Response time (ms) Response time (m
Page 69 and 70: C3: An Experimental, Extensible, Re
Page 71 and 72: HtmlParser CssParser IHtmlParser IC
Page 73 and 74: node during construction. This immu
Page 75 and 76: public interface IDOMTagFactory { I
Page 77 and 78: 3.2 JS execution Point (2): Runtime
Page 79 and 80: Extensions IE: Available from C3-eq
Page 81: extensions for web-scale use. The r
Page 84 and 85: dangerous permissions. In compariso
Page 86 and 87: Permission Popular Unpopular Plug-i
Page 88 and 89: (a) Prevalence of Dangerous permiss
Page 90 and 91: its functionality to the permission
Page 92 and 93: y ACCESS COARSE LOCATION. 358 appli
Page 94 and 95: 7 Conclusion This study contributes
Page 96 and 97: 5 discusses the pros and cons of th
Page 98 and 99: the client is free to use them how
Page 100 and 101: data it uses RESTful API which in t
Page 102 and 103: On top of Django we are using a sma
Page 104 and 105: nal design. Moreover, when the whol
Page 108 and 109: of strcpy can preclude the introduc
Page 110 and 111: Integer-valued Binary Stored XSS Re
Page 112 and 113: Java Perl PHP Number of programmers
Page 114 and 115: 0 2 4 6 8 10 0 1 2 3 Team Number La
Page 116 and 117: 0 10 20 30 Number of Vulnerabilitie
Page 118 and 119: Automated black-box penetration tes
Page 121 and 122: Abstract Integrating Long Polling w
Page 123 and 124: the Web server, the framework dispa
Page 125 and 126: all() => [Record] filter(condition)
Page 127 and 128: in any future requests associated w
Page 129 and 130: ��
Page 131 and 132: quests to be put to sleep. For exam
Page 133 and 134: Abstract Detecting Malicious Web Li
Page 135 and 136: 3 Discriminative Features Our metho
Page 137 and 138: the total number of unique IPs and
Page 139 and 140: Table 8: Detection accuracy and tru
Page 141 and 142: centraldevideoscomhomensmaduros. bl
Page 143 and 144: Web content by executing the conten
Page 145 and 146: Maverick: Providing Web Application
Page 147 and 148: must schedule USB messages to provi
Page 149 and 150: priate Web driver. USB events sent
Page 151 and 152: hardware IDs to the browser kernel
Page 153 and 154: PhotoBooth latency JavaScript drive
Page 155 and 156: delegate the higher-level abstracti
show all

2nd USENIX Conference on Web Application Development ...

Create successful ePaper yourself

Delete template?

Save as template?