2nd USENIX Conference on Web Application Development ...

More documents

Recommendations

Info

0 2 4 6 8 10 0 1 2 3 Team Number Language Vulnerable? Framework Support CSRF Session Management Password Storage Vulnerable? Framework Support Vulnerable? Framework Support 1 Perl • none opt-in • opt-in 2 Perl • none • none • none 5 Perl • none • none opt-out 3 Java manual opt-out • none 4 Java always on opt-in • opt-in 9 Java • none opt-in none 6 PHP • none opt-out • opt-in 7 PHP • none opt-out • none 8 PHP • none opt-out • opt-in Table 5: Presence or absence of binary vulnerability classes, and framework support for preventing them. Stored XSS Java 3 Java 4 Java 9 PHP 6 PHP 7 PHP 8 Perl 1 Perl 2 Perl 5 Manual Both Black-box SQL Injection Java 3 Java 4 Java 9 PHP 6 PHP 7 PHP 8 Perl 1 Perl 2 Perl 5 Manual Both Black-box SQL injection. Very few SQL injection vulnerabilities were found. Only two implementations had any such vulnerabilities, and only 4 were found in total. The difference between languages is not statistically significant (F =0.70, p =0.5330). Authentication and authorization bypass. No such vulnerabilities were found in 5 of the 9 implementations. Each of the other 4 had only 1 or 2 such vulnerabilities. The difference between languages is not statistically significant (F =0.17, p =0.8503). Figure 2: Vulnerabilities by vulnerability class. 106 WebApps ’11: <strong>2nd</strong> <strong>USENIX</strong> <strong>Conference</strong> on Web Application Development <strong>USENIX</strong> Association 0 5 10 15 20 0 1 2 Reflected XSS Java 3 Java 4 Java 9 PHP 6 PHP 7 PHP 8 Perl 1 Perl 2 Perl 5 Manual Both Black-box Authentication/Authorization Bypass Java 3 Java 4 Java 9 PHP 6 PHP 7 PHP 8 Perl 1 Perl 2 Perl 5 Manual Both Black-box CSRF. As seen in Table 5, all of the PHP and Perl implementations, and 1 of 3 Java implementations were vulnerable to CSRF attacks. Fisher’s exact test reveals that the difference between languages is not statistically significant (p =0.25). Session management. All implementations other than 2 of the 3 Perl implementations were found to implement secure session management. That is, the Perl implementations were the only ones with vulnerable session management. Fisher’s exact test reveals that the difference is not statistically significant (p =0.25).
Vulnerabilities found by Team Language Manual Black- Both Total Number only box only 1 Perl 4 1 0 5 2 Perl 3 1 0 4 5 Perl 12 3 18 33 3 Java 1 7 0 8 4 Java 2 2 0 4 9 Java 5 0 0 5 6 PHP 7 3 0 10 7 PHP 7 3 0 10 8 PHP 11 0 1 12 Table 6: Number of vulnerabilities found in the implementations of People by Temperament. The “Vulnerabilities found by” columns display the number of vulnerabilities found only by manual analysis, only by black-box testing, and by both techniques, respectively. The final column displays the total number of vulnerabilities found in each implementation. Insecure password storage. Most of the implementations used some form of insecure password storage, ranging from storing passwords in plaintext to not using a salt before hashing the passwords. One Perl and one Java implementation did not violate current best practices for password storage. There does not, however, appear to be any association between programming language and insecure password storage. Fisher’s exact test does not find a statistically significant difference (p =0.999). 4.3 Manual review vs. black-box testing Table 6 and Figure 1 list how many vulnerabilities were found only by manual analysis, only by black-box testing, and by both techniques. All vulnerabilities in the binary vulnerability classes were found by manual review, and none were found by black-box testing. We observe that manual analysis fared better overall, finding 71 vulnerabilities (including the binary vulnerability classes), while black-box testing found only 39. We also observe that there is very little overlap between the two techniques; the two techniques find different vulnerabilities. Out of a total of 91 vulnerabilities found by either technique, only 19 were found by both techniques (see Figure 3). This suggests that they are complementary, and that it may make sense for organizations to use both. Organizations commonly use only black-box testing. These results suggest that on a smaller budget, this practice makes sense because either technique will find some vulnerabilities that the other will miss. If, however, an organization can afford the cost of manual review, it should supplement this with black-box testing. The cost is small relative to that of review, and our results suggest that black-box testing will find additional vulnerabilities. Figure 2 reveals that the effectiveness of the two techniques differs depending upon the vulnerability class. 20 19 52 Black-box Manual Figure 3: Vulnerabilities found by manual analysis and blackbox penetration testing. Manual review is the clear winner for authentication and authorization bypass and stored XSS vulnerabilities, while black-box testing finds more reflected XSS and SQL injection vulnerabilities. This motivates the need for further research and development of better black-box penetration testing techniques for stored XSS and authentication and authorization bypass vulnerabilities. We note that recent research has made progress toward finding authentication and authorization bypass vulnerabilities [9, 13], but these are not black-box techniques. Reviewer ability. We now discuss the 20 vulnerabilities that were not found manually. Our analysis of these vulnerabilities further supports our conclusion that black-box testing complements manual review. For 40% (8) of these, the reviewer found at least one similar vulnerability in the same implementation. That is, there is evidence that the reviewer had the skills and knowledge required to identify these vulnerabilities, but overlooked them. This suggests that we cannot expect a reviewer to have the consistency of an automated tool. For another 40%, the vulnerability detected by the tool was in framework code, which was not analyzed by the reviewer. An automated tool may find vulnerabilities that reviewers are not even looking for. The remaining 20% (4) represent vulnerabilities for which no similar vulnerabilities were found by the reviewer in the same implementation. It is possible that the reviewer lacked the necessary skills or knowledge to find these vulnerabilities. 4.4 Framework support We examine whether stronger framework support is associated with fewer vulnerabilities. Figure 4 displays the relationship for each integer-valued vulnerability class between the level of framework support for that class and the number of vulnerabilities in that class. If for some vulnerability class there were an association between the level of framework support and the number of vulnerabil- <strong>USENIX</strong> Association WebApps ’11: <strong>2nd</strong> <strong>USENIX</strong> <strong>Conference</strong> on Web Application Development 107
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 106 and 107: [5] The spring framework. http://ww
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 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 ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?