Grammar Based Security Testing of Network Protocols
Ben Kam Thomas Dean
School of Computing Queen’s University
Kingston, Canada
[email protected] [email protected] Abstract. Security and Robustness are
increas-ingly important requirements for software systems. Our Syntax-based Security Test frame-work(SST) is designed to mutate existing confor-mance tests for text based protocols such as HTTP into security and robustness tests. The protocols are described using a grammar that is augmented with XML markup. The protocol specification is then used to guide mutators which transform the cap-tured message sequences. This paper describes the transforms to automatically mark up the captured messages and to generate message recognizers. This allows SST to mutate syntactically similar but se-mantically different messages.
Keywords. Context Free Grammars, Source Code Generation, TXL, Testing
I. INTRODUCTION
Despite widespread knowledge of classes of security bugs [18,21], vulnerabilities continue to occur. While testing cannot completely eliminate security vulnerabilities, it can increase the confidence that few vulnerabilities remain.
Binary protocols such as OSPF [17] are protocols in which the data exchanged is transmitted in a similar repre-sentation to that used in memory. For example, the integer value 4 is transmitted as the binary value 0x04 (8 bits), the value 0x0004 (16 bits) or the value 0x00000004 (32 bits). In text based protocols such as HTTP[6], use ASCII or UNICODE, and the value 4 may be transmitted as the ASCII character ‘4’ (i.e. binary value 0x34). While some binary protocols provide flexibility in lengths of fields, the number and order of fields in the messages is fixed. Syn-tactic mutations to messages such as deleting a field have little meaning, as the next sequence bytes in the message will be interpreted by the system under test as the new value for the field. Binary protocols also tend have limited support for the nesting of structures. Text based protocols have a flexible syntax, often allowing extra spaces and newline characters, and flexible ordering and deletion of fields. Thus the syntax and lexical properties of the proto-col become valid concerns for security and robustness testing.
Our previous research, called Protocol Tester [1, 19, 20, 23] handled binary protocols by translating them to a tex-tual form, mutating them using program transformation techniques and then translating back to binary format. The protocols were described using a context dependent grammar, and XML markup that specified constraints such as the types of fields or the relation between the length of
one field and the value of another. These markups are used by a test planner to insert a different set of XML markup tags into the captured message sequences to guide the mutation. While the tags used to guide the mutation is flexible and expandable, the set of tags available for use in the protocol specification is hard coded into the tool set, requiring code modification when they are extended.
Thus the goal of our new Syntax-based Security Test-ing(SST) framework is a lightweight framework capable of handling the more complex mutations for text protocols and at the same time supporting an easily extensible markup system for specifying constraints in the protocol description. The architecture of SST is similar to that of Protocol Tester. We capture request and response mes-sages that are exchanged between a valid client and the server. These are usually part of a standard conformance test set. These messages are then mutated to produce tests designed to test the security and robustness of the system under test. The messages are sent to the system using an injector that mimics the client, sending the mutated mes-sage to the server and comparing the results to the previ-ous response messages.
SST differs from Protocol Tester in several important ways. The first is that rather than using two separate sets of XML tags, the mutation markup is inserted directly into the syntactic specification [13]. From this specification an markup program is automatically generated that parses and transfers the markup to the appropriate parts of the messages. The second is that SST incorporates a message recognizer[14] (also automatically generated) that classi-fies syntactically similar messages that have semantic differences based on values within the message. For ex-ample, a grammar for HTTP does distinguish between login requests and the requests to list the contents of a shopping cart. SST allows the tester to refine the grammar based on this identification by specifying a custom gram-mar, for example to specify specific parameter names in the HTTP request header. The refined grammar also al-lows the test to specify mutation markup based on the message type.
Details of the protocol specification, mutation and the tags available are described by Kam and Dean [13,14]. This paper describes the automated process by which the protocol specification is used to generate source transfor-mation programs responsible for transferring the markup to the messages and for identifying message types. The protocol specification is also used to generate some of the transformations that implement the mutators.
Section 2 describes how markup of messages based on the protocol specification is accomplished.. Section 3 de-scribes how application specific messages are re. Section 4 describes how message specific grammar overrides are implemented by our system. Section 5 discusses the
evaluation of our system while section 6 discusses related work. Section 7 concludes the paper.
II. MESSAGE MARKUP
The protocol specification is given in two parts. The first is a context free grammar using TXL [4]. Our approach is easily adapted to other source transformation techniques such as Stratego[3], or Rascal[15]. Figure 1 shows a por-tion of the context free grammar for HTTP. It shows the definition of a request message, which consists of a re-quest line followed by zero or more headers and an op-tional message body. Figure 1 also shows the definition of a request line and the method in the request line. We use TXL in character mode which explicitly matches whitespace as tokens in the grammar (the [space] token matches one or more whitespace characters other than newline). The definition of method enumerates the possi-ble HTTP message requests as a set of literal values.
Figure 2 shows a sample markup specification. In this case it marks up the method non-terminal of the request line definition. In this case, enumeratedLiteral and caseSensitive tags are used to mark the method of the request line. A simple program is used to replace the definitions of the original grammar with the definitions from the markup specification. This becomes the com-bined protocol description.
The combined protocol description file is used to gener-ate the working grammar that will be used by various pro-grams in the system. Unique non-terminals are generated
for each mark-up sequence, including any nested se-quences. Figure 3 shows the working grammar generated from Figs. 1 and 2. In Fig 3, two non-terminals are gener-ated, markable_method1 and markable_method2. The non-terminal markable_method1 is used to repre-sent the sequence in the original definition, and it in turn uses markable_method2 to represent the nested markup, which, in turn, invokes the original non-terminal method. Since the request language may include XML (e.g. SOAP[7]), a configuration file listing the markup tags recognized by the system is used to distinguish be-tween XML tags in the protocol and markup used by SST.
Since the captured messages do not contain markup, a second grammar file is generated that makes the markup optional. Figure 4 shows the optional grammar file gener-ated from Figures 1 and 2. In this grammar, the TXL redefine keyword is used to override the previous definition, and ellipses (“...”) reference the previous defi-nition. Thus a markable_method1 is either a mark-able_method2, or a markable_method2 sur-rounded by caseSensitiveTags (from figure3). A. Simple Markup
The markup insertion program uses both the working grammar and the optional markup grammar. It consists of a single driver rule and a set of rules generated at the same time as the working grammar. Figure 5 shows the rules generated from Figs. 1 and 2. The rules find each instance of the generated non-terminals and add the markup. For
% partial HTTP grammar
define program [request-message]
end define
define request-message
[request-line][repeat headers_message] [CRLF][opt message_body] end define define request-line [method][space][request-uri][space] [http-version][CRLF] end define define method
OPTIONS | GET | HEAD | POST | PUT | DELETE | TRACE | CONNECT
end define
Figure 1: Context free protocol grammar
define request-line <enumeratedLiteral><caseSensitive> [method] </caseSensitive></enumeratedLiteral> [space][request-uri][space] [http-version][CRLF] end define
Figure 2: Context free protocol grammar
define request_line
[markable_method1] [space] [request_uri] [space] [http_version] [CRLF] end define define markable_method1 [enumeratedLiteralStartTag] [markable_method2] [enumeratedLiteralEndTag] end define define markable_method2 [caseSensitiveStartTag] [method] [caseSensitiveEndTag] end define define enumeratedLiteralStartTag <enumeratedLiteral> end define define caseSensitiveStartTag < dateSpecific > end define define enumeratedLiteralEndTag </ enumeratedLiteral > end define define caseSensitiveEndTag </dateSpecific > end define
example, the rule insert_markable_method1 visits each markable_method1 non-terminal and replaces the markable_method2 with a version annotated with the enumeratedLiteral tag. The rule insert_mark-able_method2 does the same for the mark-able_method2 non-terminal and the caseSensi-tive tag.
For some tags, such as caseSensitive, the place-ment of the tag is grammar dependent, but mutation is grammar independent. For other tags, such as enumer-atedLiteral, the mutator is grammar dependent and must be generated from the protocol description. Figure 6 shows one of the mutation rules generated for the enu-meratedLiteral tag given in Fig. 2. In this case, if the request method is marked up, and is not the literal value OPTIONS (the deconstruct not clause), then it is replaced by the literal value OPTIONS(using the function replaceMethodOptions). After the method is replaced, the mutated message is written to a file (writeMutantFile). A similar rule is generated for each literal value derived by the method non-terminal (i.e. OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT).
B. Relation Tag Markup
Unlike simple markup which is used to identify single sequences of text to mutate (such as the request method or the agent header), Relations tags mark multiple related parts, such as the content-length header and the message body. Another example is when multipart
encod-ing is used. In standard encodencod-ing, the values of the pa-rameters are all text and encoded as part of the URL or as a single line in the message body. In multipart encoding, each parameter is given its own set of headers, allowing each parameter to be of a different type. This allows the browser to upload alternate data items such as image files or audio clips. The type relation tag can be used to link the content type header to the associated content type. In this case there would be multiple instances of the relation tag (one for each parameter). Relation tags are distin-guished by the id attribute.
Figure 7 shows an example of the use of the length and type markup. The first part of Fig 7 gives the defini-tion of the content length header and of the message body. The other attribute required by relation tags is the root attribute. This is the non-terminal in which the relation tag is unique. Since there is only one length attribute in an HTTP message, the root is request_message non-terminal. The second part of Fig 7 shows a use of the type relation tag. This tag is used in the definition of partial_body (used to parse multi part messages) and the content type header. The content of partial body (after the headers), is defined as a sequence of tokens that is not a boundary token. Since there will be a separate type markup for each parameter, the root is given as parti-al_body.
Both tags use one more attribute, the role attribute. This attribute is not used by the markup engine, but is copied verbatim to the message when it is marked up. It is used to pass extra information to the mutator. Thus the implementation of the length mutator is entirely grammar redefine markable_method1 [markable_method2] | ... end redefine redefine markable_method2 [method] | ... end redefine
Figure 4: Optional protocol grammar
rule insert_markable_method1 replace $ [markable_method1] M1 [markable_method2] by <enumeratedLiteral> M1 </enumeratedLiteral> end rule rule insert_markable_method2 replace $ [markable_method2] M2 [method] by <caseSensitive> M2 </caseSensitive> end rule
Figure 5: Markup methods
function enumeratedMethodOPTIONS baseFileName [stringlit] replace [program] P [program] deconstruct *[markable_method1] P <enumeratedLiteral> M2 [markable_method2] </enumeratedLiteral> deconstructnot *[method] M2 'OPTIONS
construct PMutant [program] P [replaceMethodOPTIONS] construct _ [program]
PMutant [writeMutantFile baseFileName] by P end function function replaceMethodOPTIONS replace * [method] _ [method] by 'OPTIONS end function
independent as the role attribute is used distinguish the role the content marked plays in the mutation. In the case of the length tag, it distinguishes the value of the length from the message body, and in the case of the type tag, it distinguishes the mime-type from the partial message con-tent. All attributes other than the id and root tags are cop-ied verbatim allowing the tester to parameterize the muta-tor depending on the context.
Figure 8 shows a HTTP request message that has been marked using these tags. The content length header at the top of the message has been annotated with a length tag as well as the entire message body. The message has two
parameters, bar and bat, which have been encoded as multipart The first parameter, bar, contains a png image file (icon-users.png). The second parameter, bat, has a text value of “hello world”. The Content-Type header of the parameter values have been marked with the type tag including the values of the parameters. In all three cases, the “%” character in the id attribute has been replaced with a unique value (the value 1 for the length tag and the values 2 and 3 for the type tag). This allows the mutator to identify which instances of the tags are related. Thus a mutator of png image files can look for a type tag with a role attribute of type, and then mutate define Content_Length
Content-Length : [space]
<length id="%" root="request_message"
role="length" >[content_length_number]</length>
end define
define message_body
<length id="%" root="request_message" role="value"> [repeat partial_body] [end_boundary] </length> [CRLF] end define define partial_body [boundaryToken] [CRLF] [repeat entity_headerCRLF] [CRLF]
<type id=”%” root=partial_body role=”value”> [partial_body_content] </type> [CRLF] end define define partial_body_content [repeat body_content] end define define body_content
[not boundaryToken] [token]
end define
redefine Content_Type
Content-Type : [space] <type id=“%” root=“partial_body” role=“file type ”> [mime_value]</type>
end define Figure 7: Relation tag use
POST /~dean/cgi-bin/test HTTP/1.1 Connection: keep-alive
Referer: https://cetus.ee.queensu.ca/~dean/multi.html
Content-Type: multipart/form-data; boundary=---159472411512557918151295388397 Content-Length: <length id="1" root="request_message" role="length">3895</length>
<length id="1" root="request_message" role="value">--- 159472411512557918151295388397
Content-Disposition: form-data; name="foo"
---159472411512557918151295388397
Content-Disposition: form-data; name="bar"; filename="icon-users.png"
Content-Type: <type id="2" root="partial_body" role="type">image/png</type>
<type id="2" root="partial_body" role="value">f3j9”y#9W“Ð@AÕÊT¢û•ðØ“óã= äDâ\-•[ Î hÊnF_ÕsÿÿÇ-ïóøTMø?cþÒ3⁄4 ç<null/><null/><null/><null/>IEND®B`‚</type>
---159472411512557918151295388397--Content-Disposition: form-data; name="bat"
Content-Type: <type id="3" root="partial_body" role="type">text/plain</type> <type id="3" root="partial_body" role="value">hello world</type>
---159472411512557918151295388397-- </length> Figure 8: Relation tags in messages
the contents of the type tag with the same id attribute. Note also that the content type header that is outside of the message body has not been marked.
Figure 9 shows the rules generated from the grammar to insert the type tags into the captured messages. It con-sists of two parts. The first part (SubrootRule_par-tial_body) visits each instance of the non-terminal that was given by the root attribute. It also increments a global variable (gbluid) which is used to generate the unique value for the id attribute. The rule then invokes a custom generated rule for each of the instance of the type tag in the protocol specification.
The first, isertmarkable_method2 adds the markup to the mime value in the content-type header. The second, insertmarkable_method4 adds the markup to the value of the parameter.
III. IDENTIFICATION AND GRAMMARS The previous section dealt with markup of messages based on a generic protocol specification that describes all of the messages in the protocol. However, applications using the protocol can add an extra layer of semantics to the protocol. For example, in the HTTP protocol, no struc-ture is given for the message body, since the strucstruc-ture is given by the content-type header. Browsers encode the POST content as the mime type application/x-www-form-urlencoded, in which the forms
parame-ters and values are given on a single line separated by the ‘&’ or ‘;’ characters. However, web applications can also encode in alternate formats such as SOAP, or simply send raw data in the message body. As such, the general HTTP grammar parses the message body as a generalized se-quence of tokens as shown in Figure 10. The terminal symbols token and key match either a non-keyword token or a keyword respectively. Thus the message body definition consumes all input up to the end of the message.
Even if the general HTTP grammar allows the tester to parse HTTP parameters and values that will be passed to the server, it cannot distinguish between a login request from a search request. The web application is free to use whatever names of parameter it chooses to. In addition, parameter values may, in turn, be structured in various ways. SST provides a notation for specifying the applica-tion level of the protocol. The applicaapplica-tion level specifica-tion includes three elements, general grammar extensions, patterns to identify messages and message specific markup. The format and use of the specification is covered elsewhere [14].
rule SubrootRule_partial_body replace $ [partial_body] M [ partial_body ]
construct NewM [partial_body] M [insertmarkable_method2] [insertmarkable_method4] import gbluid [number] export gbluid gbluid [ + 1 ] by NewM end rule function insertmarkable_method2 replace * [markable_method2] M7 [mime_value]
construct M8 [repeat token_or_key] _ [reparse M7]
deconstructnot M8 _ [empty]
import gbluid [number]
construct uid [stringlit] _ [quote gbluid ] by
<type id=uid root="partial_body" role="file type"> M7 < / type >
end function
function insertmarkable_method4 replace * [markable_method4] M9 [partial_body_content]
construct M10 [repeat token_or_key] _ [reparse M9]
deconstruct not M10 _ [empty]
import gbluid [number] construct uid [stringlit] _ [ quote gbluid ] by
<type id=uid root="partial_body" role="value" > M9 </type>
end function Figure 9: Rules to insert type relation tag.
function checkIfLogin BaseFileName [stringlit] replace [program]
P [ program ]
deconstruct *[request_uri] P Content0 [request_uri] construct ContentStr0 [stringlit] _ [ quote Content0 ]
where
ContentStr0 [grep "cmd=login"] construct _ [stringlit]
BaseFileName [write ‘Login] by
P
end function
Figure 11: Rule to identify Login Packets.
define message_body [repeat token_or_key] end define define token_or_key [token] | [key] end define
The general grammar extensions are inserted to the pro-tocol grammar in a strait forward manner. They are then used by the identification patterns. These take the form of a non-terminal and a regular expression. Rules are gener-ated to search for the regular expression in instances of the non-terminal. Figure 11 shows an example of identifying a login message. In this case, the message is a login mes-sage if the request URI contains the string “cmd=login”. The rule converts the URI non-terminal to a string and uses the grep rule to check for the sub-string. If so, it writes the literal value Login to the log file, allowing the script running the program to properly classify the message.
Once the message has been identified, message specific grammars can be applied. For example, browser requests using the GET protocol typically pass the parameters as part of the URI, while browser requests using the POST protocol pass in the message body. Figure 12 shows a message specific grammar used for handling non multipart form messages. The rule to add the tags to the message is shown at the end of Figure 12. The TXL reparse rule takes the set of tokens parsed by one non-terminal (mes-sage_body) and invokes the parser using a different non-terminal (new_message_body). THus M1, which is a sim-ple sequence of tokens (grammar in Fig 10), is parsed as a sequence of ParamNameValuePair. The implementa-tion addTags rule is similar to the rules given in Secimplementa-tion III, inserting markup into the newly parsed tokens. After,
the contents are parsed back to the token sequence of the original grammar.
Protocol grammars are extremely ambiguous. Even though TXL supports parsing of ambiguous grammars, the reparsing approach allows the tester to use the main grammar to segment the input and to write simpler gram-mars to parse each segment separately.
Figure 13 shows an example of a message that has been both marked up using the grammar and rule in Fig 12. The message body has been marked up with several tags. These include the LexicalForm, LegalChars, Length and CaseSensitive tags. Attributes of the tags give extra information to the mutators to assist in making changes.
IV. EVALUATION
SST has been demonstrated using two protocols, HTTP [6] and iCalendar [5]. We started by constructing a toy application which contained instances of the vulnerabili-ties exercised by the currently implemented mutators. Other tests included a demo version of an image gallery application and kOrganizer (an open source calendar ap-plication). In both cases, vulnerabilities were discovered in the software. A cross site scripting vulnerability was dis-covered in the image gallery application [14], and a buffer overflow in the Qt interface widget set was found through the testing of kOrganizer [13].
define new_message_body [ParamNameValuePair] [repeat and_ParamNameValuePair][CRLF] end define define ParamNameValuePair [ParamName] '= [ParamValue] end define define ParamName [id] end define define ParamValue
[opt startTag] [repeat anything_but_not_space] [opt endTag]
end define
define anything_but_not_space [not '&][not space][token_or_key] end define define and_ParamNameValuePair '& [ParamNameValuePair] end define function addTagsToLogin replace $ [message_body] M1 [message_body]
construct M2 [opt new_message_body] _ [reparse M1]
[addTags]
construct Replacement [message_body] _ [reparse M2]
by
Replacement end function
Figure 12: Message specific markup implementation
POST /login/?cmd=login HTTP/1.1 ...
Content-Length: 58
username=<LexicalForm p="[\a\d]+"><LegalChars p="\a\d"><Length p="1-20"><CaseSensitive p="yes">test-student</CaseSensitive"></Length></LegalChars></LexicalForm>&password=<LexicalForm p="[\a][!@#$%&_\d]*[\a][!@#$%&_\a\d]*"><LegalChars p="!@#$%&_\a\d"><Length p="2-30"><CaseSensitive p="yes">testp%40%24%24</CaseSensitive></Length></LegalChars></LexicalForm>&submit=Login
V. RELATED WORK
There is a great deal of research on security testing of web application. Much of this research focuses on SQL injection, cross-site scripting and command injection. Some research also provides method to generate guards in the applications from the models. User input strings must be passed through the guards for security checking prior to accessing the database. Jing et al [11] use a non-deterministic finite state machine to mutate packets. How-ever their approach, like our previous research is focused on binary protocols. Text is more flexible and less suscep-tible to value changes.
Aitel’s block-based network protocols security testing [2] is the most similar to SST. However, the test cases generation obtained by random fuzzing variables only breaks the syntactic constraint of the protocol grammar. SST, in addition to generating random fuzzing values, also provides different types of markup tags to violate syntactic and semantic of the protocol grammar. For example, rela-tional type markup tags break the semantics relationship between terminals.
Guido et al [12, 22] use the relational calculus and automata to formal model the system’s required security requirements. Their security testing only can test applica-tion level security. SST not only can test applicaapplica-tion level security, but also low level and middle communication protocol level security.
Halfond et al [8, 9] propose a combination of static and dynamic analysis for SQL injection protection of web application. For the static part, they build models based on static analysis of the source code that contains all of the possible legitimate SQL queries in a PHP application. Test cases generation is accomplished by injecting additional SQL statements into a query to intentionally violate the model. The dynamic analysis incorporates the comparison of runtime queries with the static model. If the dynamic query violates the model, execution is halted and noted.
Merlo et al [16] use dynamic analysis of legitimate test cases and security scenarios to build static models corre-sponding to the call site. A query invocation at the call site will be compared to the corresponding model to check whether or not it is a legitimate query. Both approaches focus on SQL injection, and do not address cross- site scripting or command injection. The approach of Merlo et al has the advantage of not relying on the source code and thus is capable of testing SQL-injection by malicious code. Their method can be reused for other languages but an execution environment with appropriate instrumenta-tion is required.
V. CONCLUSIONS AND FUTURE WORK There are several opportunities for future expansion of the system. The first is that some information and markup can be deduced automatically. For example, the enumerated literal markup tag could be inserted automatically based on an analysis of the grammar. Similarly, the root attrib-ute of relations tags could also be automatically inferred by selecting the least common ancestor of all grammar definitions containing the relationship tag. This would not require a change to the system, simple a preprocessing rule that inserts the existing tags when the corresponding grammar cases are detected, or adds missing root attrib-utes.
The most obvious expansion is to increase the number of markup tags and mutators. Grammar independent tags are easy to add, simply add the name to the tag library and provide an appropriate mutator. However a more interest-ing avenue of pursuit is tags that are dependent on gram-mar structure. Two examples of such mutations include removing syntactic delimiters and altering order of fields.
All of the current mutators are specific to single markup tags. However, as noted by Harman et al [10], combining multiple mutations in standard mutation can reveal errors not revealed by single mutants. The same may be true for data mutations.
In conclusion we have presented a series of source transformations for protocol testing that are automatically generated from a protocol specification. The protocol specification consists of a grammar for the protocol syntax which is augmented by XML markup. The markup system is easily extensible, allowing the tester to add arbitrary tags. The markup is also orthogonal to the mutation sys-tem allowing mutators to be written to mutate individual, or combinations of markup.
REFERENCES
[1] AboElFotoh, M., Dean, T.R., Mayor, R, “An Empirical Study of a Language Based Security Testing Technique”, Proc. 19th IBM Centres for Advanced Studies Conference, Toronto, Canada, November 2009, pp 112-121.
[2] Aitel., D., “The Advantages of Block-Based Protocol Analy-sis for Security Testing”, http://citeseerx.ist.psu.edu/ viewdoc/download?doi=10.1.1.116.1178& rep=rep1& type=pdf, last accessed 2010.
[3] Bravenboer, M., Kalleberg, K. T., Vermaas, R., Visser, E, “Stratego/XT 0.17. A Language and Toolset for Program Transformation”, Science of Computer Programming, 72(1-2):52--70, June 2008
[4] Cordy, J.R., "The TXL Source Transformation Language", Science of Computer Programming 61, 3 (August 2006), pp. 190-210.
[5] Dawson F., Stenerson D., “Internet Calendaring and Sched-uling Core Object Specification(iCalendar),” Lotus, Micro-soft, IETF RFC 2445, 1998.
[6] Fielding R., Irvine UC, Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners-Lee T., “Hypertext Transfer Protocol - HTTP/1.1,” Compaq/W3C, Compaq, W3C/MIT, Xerox, Microsoft, W3C/MIT, IETF RFC 2616, 1999 [7] Gudgin, M, Hadley, M, Mendelsohn, N, Moreau, J, Frystyk,
H, Karmarkar, A, Lafon, Y, “SOAP Version 1.2 Part 1: Mes-saging Framework (Second Edition),” W3C Recommenda-tion, 2007
[8] Halfond W. G. J., Orso A., “AMNESIA: Analysis and Moni-toring for NEutralizing SQL- Injection Attacks”, Proceed-ings of the 20th IEEE/ACM international Conference on Automated software engineering (ASE '05), pp. 174-183, 2005.
[9] Halfond W. G. J., Orso A., “Combining static analysis and runtime monitoring to counter SQL-injection attacks”. In Proceedings of the 3rd International ICSE Workshop on Dynamic Analysis (WODA), IEEE Computer Society Press, pp. 105-110, 2005.
[10] Jia, Y., Harman, M., “Higher Order Mutation Testing”, Journal of Information and Software Technology, Vol. 51(10), 1379-1393, 2009.
[11] Jing C., Wang Z., Shi X., Yin X., Wu J., “Mutation Testing of Protocol Messages Based on Extended TTCN-3”,
Pro-ceedings of the 22nd International Conference on Advanced Information Networking and Applications, pp. 667 – 674, 2008.
[12] Jurjens J., Wimmel G “Formally Testing Fail-safety of Elec-tronic Purse Protocols”, Automated Software Engineering, IEEE Computer Society, pp. 408 – 411, 2001.
[13] Kam, B., Dean, T., Linguistic Security Testing for Text Communication Protocols, TAIC PART, Windsor, UK. Sep-t e m b e r 2 0 1 0 , s u b m i Sep-t Sep-t Sep-t e d ( d r a f Sep-t a v a i l a b l e a Sep-t http://post.queensu.ca/ ~trd/pubs/taic10.pdf.
[14] Kam, B., Dean, T., Security Testing of Application Specific Messages”, in preparation, draft available at http://post .queensu.ca/~trd/research/papers/kamSSTApp.pdf
[15] Kllint,P., vand der Storm, T., Vinju, J., “RASCAL: A Do-main Specific Language for Source Code Analysis and Ma-nipulation”, Ninth IEEE International Working Conference on Source Code Analysis and Manipulation,Edmonton, Canada, September 2009, pp. 168-177
[16] Merlo E., Letarte D., Antoniol G., “Automated Protection of PHP Applications Against SQL-injection Attacks”, Proceed-ings of the 11th European Conference on Software Mainte-nance and Reengineering, pp.191-202, 2007.
[17] Moy, J, “OSPF Version 2”, Internet RFC 2328, 1998 [18] OWASP, The Open Web Application Security Project,
http://www.owasp.org/, last accessed: 2009.
[19] Tal O., Knight S., Dean T. R., “Syntax-based Vulnerabilities Testing of Frame-based Network Protocols”, Proceedings of the Second Annual Conference on Privacy, Security and Trust, 2004.
[20] Turcotte Y., Oded T., Knight S., Dean T. R., “Security Vul-nerabilities Assessment of the X.509 Protocol by Syntax-Based Testing”, Proceedings of MILCOM 04 on Military Communications Conference, pp. 1572 – 1578, 2004. [21] WASC Projects. “Web Application Security Consortium,
Threat Classification.” http://projects.webappsec.org/ Threat-Classification/, last accessed: 2008.
[22] Wimmel G., Jurjens J., “Specification-based Test Generation for Security-Critical Systems Using Mutations”, ICFEM, LNCS, Springer-Verlag, pp. 471-482, 2002.
[23] Zhang S., Dean T.R., Knight G.S., “Lightweight State Based Mutation Testing for Security”, Proc TAICPART-MUTATION 2007 , Windsor, UK, pp. 223–232, 2007.
