Sunteți pe pagina 1din 8

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No.

6, June 2011

The History of Web Application Security Risks


Fahad Alanazi
Software Technology Research Laboratory

De Montfort University Leicester, LE1 9BH UK P0800238x@mydmu.ac.uk

Mohamed Sarrab Software Technology Research Laboratory De Montfort University Leicester, LE1 9BH UK msarrab@dmu.ac.uk
employed to protect them.This paper will identify and discuss ten web applications vulnerabilities, which constitute a threat to web applications security; assessing information provided by researchers and OWASP regarding risk assessment and protection. II. INJECTION FLAWS In 2007 OWASP [30] mentioned numerous Injection flaws including: SQL, LDAP, XPath, XSLT, HTML, XML and OS; with SQL being the most common of such injection types. In 2004 OWASP [29] cited the main cause of vulnerability in web applications to be there use of features of the operating system and external programs to implement functions. This enables attackers to exploit previous information from an HTTP request, to inject malicious code as the web application passes information through. The attack occurs when data is sent to the interpreter after the user has initiated a command or query. The attacker exploits this situation with the injection of malicious code alongside the command or query, which enables full access to the system bypassing any protection and calling for data from operating systems and databases.OWASP in 2010 [31] described this type of attack, as the attacker sending simple text to exploit the syntax that targets the interpreter. Almost all data sources use an injection vector which includes internal sources. This flaw is typically found in SQL queries, LDAP queries and OS commands [21]. Recommendations Avoid using interpreters if possible. Input validation. Avoid detailed error messages that may be useful to an attacker. Reject all script injection (Gregory (2009).

Abstractthis article refers generally to current web application risks that are causing public concern, and piquing the interest of many scientists and organizations, as a result of an increase in attacks. The primary concern of many governments, organizations and companies is data loss and theft. Thus, these organizations are seeking to insure their web applications against vulnerabilities. Revealing that awareness of the vulnerabilities of web applications leads to recognition of the need for improvements. The three main facets of web security are: confidentiality, integrity and safety of content, and continuity. This paper identifies and discusses ten web application vulnerabilities, detailing the opinions of researchers and OWASP regarding risk assessment and protection. I. INTRODUCTION

The Internet is a fascinating and multi-faceted technology, opening a window on the world by allowing people across the globe to access information simply and quickly; allowing them to broadcast their ideas and culture, communicate and access research data from anywhere. It is now even seen as a form of e-government; based on its achievements in the last four years and the acquisition of 300 million users. However, the Internet lacks geographic borders, or national controls and this has led to concerns about the security of conducting business online. Indeed; there are those who expend considerable effort in seeking to penetrate and steal important information from websites, justifying apprehension amongst the owners of this information and electronic service providers. Therefore, companies are doing their utmost to maintain the confidentiality, privacy and accuracy of information they hold (integrity); systems can now be protected in a number of ways and some of the programs that have helped in intrusion detection and reducing viruses have somewhat eased the trepidation of network users. Recently attackers have turned their focus to web applications which allow surfing, shopping, communication with companies in other countries, etc. This is because they rely on databases to facilitate information exchange and the distribution of information. These applications have an increasing number of users, increasing their attractiveness to attackers, despite the numerous programmers and developers

SQL Injection SQL injection is common among injection flaws, and yet applications those are vulnerable to itare used in our daily

40

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

lives, relying on their safety; e.g. for making bookings and paying bills. As the number of such applications increases, so does the sophistication of the attacks that target them. The hackers use many methods to create defects in web applications; of these SQL injection is one of the easiest and most dangerous, potentially damaging the whole system. SQL injection is an attack in which SQL code is inserted or appended into application user input parameters that are later passed to a back-end SQL server for parsing and execution [8]. SQL injection is a serious threat to any site or application that contains a database; by injecting, and executing, the SQL code with basic code, attackers can gain unauthorized access to private databases containing important and secure information, thus compromising the integrity of sensitive data by allowing for alteration or deletion [2]. SQL injection attacks affect authentication processes impinging on the verification of user identity and allowing attackers to connect to the system without the password by using the query language injection. Preventing SQL injection String input must use two single quotation marks rather than a single quotation mark. If there is single quotation mark this should be replaced by two single quotation marks [10]. Verification occurs from a single quotation mark in the inputs field, so if there is a single quotation it should be remove. Verification and removal of TSQL comments such as and /**/ because these comments might damage the data. Detection and verification of TSQL keywords such as SELECT, which might be used to query specific elements. Ensure clients and server input. Use of elaborate SQL constructs that might cause errors and impede the execution of injected code. Verification from system records to limit the number of users that do not have/do have an account in the system to detect any unauthorized access to the system by comparing these numbers. Use a secure policy for the system; by determining permissions, for example limiting some permission to only reading and writing [16].

III.

Cross Site Script (XSS)

Cross site scripting is another intrusion method that manipulates the web browser to display malign code, which then initiates in the users session. This can be done in a number of ways typically in Hypertext Markup Language [HTML] [15]. Cross site scripting can be used in a number of ways from theft of a cookie to taking over an entire session. This is referred to as an intruder guided attack [18]. Insertion of a script into a field can be an efficient attack but circumventing the filter can be a problem. Cross site scripting uses an array of methods for abuse and intrusion [15]. According to Ciampa[11] a Cross Site Script (XSS) attack is characterized by the use of special engineering; allowing the attacker, through the use of JavaScript language, to extract important information from the victim before utilizing it. Lopez and Hammerli [24] argue that XSS is targeted on the web applications site and uses either stored XSS or reflected XSS. The hackers attempt to attack users browsers and take control with malicious script. When an attack is successful, the attacker can access important resources in the web application; i.e. Cookies. According to Belapurkar et al [5] these attacks rely on users to input information and this means attackers can inject dangerous code whilst inputting data to gain access to the site. The XSS often occur when the web application requires input via a Username and Password page, as attackers can benefit from this by tricking the user. In addition, any script entered in/form fields or in an URL is likely to pose a risk to the site of this type of attack. XSS depends on injecting client-side script, leading to account theft and changes to the content on a page. XSS occurs when the web application fails to escape user-submitted content properly before rendering it into HTML [19]. OWASP cited the ability of attackers to use XSS to send malicious code or script to an unsuspecting user, affecting sensitive and important information that the browser has maintained as well as cookies and session tokens. The malicious script can rewrite and rephrase the contents of the HTML page because the browser does not know the origin of the script, or whether it can be trusted.OWASP divided this type of attack into two categories: Stored: This attack is occurs through injection of malicious code or script into the target server and is stored permanently in messages, comment forums or databases etc. If/when the user requests information, the stored malicious script information is transferred to the server. Reflected: This type of attack is the most common type and is reflected off the web server as in an error message. This type of attack tricks the user when they click on links where malicious script or code has been entered.

41

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

OWASP highlights the dangers of disclosure. When attackers hijack users sessions, full control is gained and the attacker can access end user files. The attacker can also redirect the user to pages or other sites and can modify presentation of content by installing Trojan programs. Therefore, OWASP recommend verification from inputs and filtering to scripts because most XSS attacks occur in JavaScript.XSS attack is dangerous for applications and servers due to the fact that most of these display simple web pages that contain errors such as 500 internal server error. These may include information which enables attackers to corrupt the server and the users browser by reflected attack. In 2007, OWASP [30] referenced cross site script as a subset of HTML injection. In this type of attack the victims browser is exploited by the attacker through executed script by user sessions. All malicious scripts are related to JavaScript, but any scripting language supported by the victims browser may be vulnerable to this type of attack. OWASP described all the associated web applications that are vulnerable to three types of XSS attack: Reflected XSS: Easiest for exploiting the page. Stored XSS: The most dangerous is that it can take hostile data, store it within a file or database then at a later time display the data for the user without a filter to detect input to the website. DOM based XSS: The JavaScript and variables are being manipulated rather than HTML elements.

Use XSS filter to detect any malicious code [23]. Avoid special characters in input box such as <>, , % , ; ) because these characters can help the attacker to acquire sensitive data. Limit the data that might be a part of scripting attack [17]. IV. Buffer Overflow

Buffer Overflow is an attack that occurs when web applications have no control over input that might contain commands, encoding or improper formats. The attacker uses buffer overflow by inputting and overrunning the memory space which is used by the operating system [6]. Dubrawsky [12] argued that buffer overflow happens when the attacker inputs additional information into the buffer that is (a holding area for data) that cannot handle. Buffer overflow attack relies on programming language work that includes C and C++. The buffer overflow occurs when the memory size exceeds the allocation for a buffer as a result failure to limit the inputted information. Furthermore, it occurs when the web applications use low-level programming languagesbecause these languages do not perform automated bounds checking. Buffer overflow can happen if data is not checked for the length of value when copying it into the buffer from another source, i.e. a Network socket [7]. This agrees with supports Wells [35] argument that storage flaws affects web application security. According to Wells security measures must be employed which include data encryption because web applications could contain sensitive information. Buffer overflows are in essence a technique used when data is written into a fixed sized memory block resulting in memory around the destination buffer becoming jammed and over capacity. This would give the intruder access to parts of the processing memory allowing for the entry of malign code [13]. This involves writing data to places in the memory stack that contain information about the operating system, if this data is accessed and overwritten then this usually results in a machine crashing and the system resetting; the intruder can also make the process memory point to his code, which could result in passwords being accessed or new accounts being created [9]. The best way to overcome this kind of attack is to completely avoid using a memory management system [13]. OWASP [29] referred to web application components being improperly validated in some languages, leading to buffer overflow attacks to access the system. This type of attack is difficult to detect and eradicate when discovered. Buffer overflow can be found in the web application or both the web server or application server products that serve the static and dynamic aspects of the site. It can be found in custom web application code but detection buffer overflow flaws are less

OWASP did not concentrate on these three areas, as in addition there is a possibility of risky and unpredictable browser behaviors which may lead to attack. XSS may affect any components that the browser uses. JavaScript allows for attack due to its strengths as a programming language which allows manipulation of the rendered page by adding new elements, internal DOM, changing or deleting the page. Additionally, this type of attack permits use of XmIHttpRequest because attackers can circumvent the browser and forward the victims data to aggressive sites, then create malicious codes to force open the browser for a long period of time. Recommendations Encode sensitive data. Validate input data for length. To detect XSS in input donot use blacklist. Before using any untrusted data HTML tags should be removed [14].

42

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

likely in custom web applications. If a custom application is discovered, the ability of the attacker is reduced, because the source code and detailed error messages for the application are normally not available to the attacker. To determine if the server products are vulnerable there should be a review of all code that accepts input from users via the HTTP request to ensure that it can properly handle arbitrarily large input and ensure that it provides appropriate size checking on all such inputs. Buffer overflow was not mentioned in OWASP [30] or [31] because it was detected by either an; Intrusion Detection System or IDS software, hardware or a combination of both.There are two types of IDS: Network intrusion detection system: This can capture data packets travelling on the network. Host-based intrusion detection systems: These can look into the system and application log files to detect any intruder activity.

where mistakes have commonly been made; unencrypted critical data; insecure storage of keys, certificates, and passwords; improper storage of secrets in memory; poor randomness selections; poor choice of algorithms; attempting to invent new encryption algorithms; failure to include support for encryption key changes and other required maintenance procedures. Therefore, all websites which use encryption to protect sensitive and important information in storage and transit are vulnerable to these kinds of attacks. Detection of these flaws takes place in the following ways: Examine tokens, session IDs, cookies and other credentials to see if they are obviously not random. As a means of protection from this type of attack OWASP recommended a preference for re-entering data and not storage. OWASP also proposed, where a need to use encryption exists, utilizing a library that is exposed to public scrutiny and make sure that there are no open vulnerabilities [26, 29]. In 2007 OWASP [30] cited failure to encrypt sensitive information in web applications to be the result of poorly designed cryptography. There are many associated cryptographic flaws that use inappropriate or strong ciphers, which may lead to the discovery of sensitive data. As a result OWASP mentioned that all web applications are vulnerable.These were the most common problems in 2007. Not encrypting sensitive data using home grown algorithms; insecure use of strong algorithms; continued use of known weak algorithms (MD5, SHA-1, RC3, RC4etc.); hard coding keys; and, storing keys in unprotected stores.OWASP [31] again stated that the most common flaws relate to not encrypting data, however, due to limited access precise flaws are difficult to determine. Recommendations Use only public algorithms. Avoid using weak algorithms. Infrastructure credentials for web application such as database credentials should be securely encrypted [21]. To protect insecure storage one must use proper encryption and access control for all data that is stored [17]. VI. Cross Site Request Forgery (CSRF)

Recommendations Do not use C and C++ programming language when building a web application [32]. Limit input data to prevent long input strings that might include malicious code [17]. V. Insecure Cryptographic Storage

Web applications sometimes use cryptographic functions in order to secure data. Unless these functions are coded properly, this is not an easy thing to do.They can only offer a weak form of protection. Applications that do not offer a good level of protection often use inappropriate ciphers. Thus, it is advisable to ensure that everything is to be encoded is encoded [21]. Recommendations: One should use only approved public algorithms. These include AES, RSA and public key. Cryptography stores private keys with care. Try not to submit key over channels that are not guaranteed secure [21].

In 2004 OWASP [29] highlighted this type of attack because most web applications need to store sensitive and important information such as passwords and account records in a file system or database. Web applications developers thus resort to encryption to protect this important information. However some developers have made mistakes whilst integrating encryption into their web applications, they have also failed to focus on other aspects of the site. There are several areas

Cross Site Request Forgery (CSRF) relies on XSS attack to input dangerous code to the end users browser. This type of attack does not target the site that is implemented in these malicious codes but tricks the user to access other sites. CSRF affects web applications because it allows the attacker to change the victims stored information e.g. password [13].Holovaty and Kaplan-Moss [19] show that CSRF occurs

43

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

when the attacker tricks the users by loading an URL from an authentication site to take advantage of their sites. According to Kategorileri [21], Broken Authentication and Session management cause privacy violations. These flaws might lead to hijacking of administrative or user accounts, given the fact that there is no protection for credentials and session tokens throughout a web applications lifecycle. A cross site request forgery is an intrusion that is a request for a page that appears to be sent from a trusted user. One common example of this is when an image on a page is embedded; this contains a link to a PHP script [4, 15, 33]. Such intrusions can be used to gain entry to password protected parts of a website. If an intruder has convinced a user to log onto a web application, then it can be used to access to malign JavaScript. This can take over the users session by releasing a false POST, using the users existing session [22]. Cross site request forgery intrusion can also be initiated by sending a fake HTTP request from the users session. This can send information such as the users session cookie and other authorisation information. This is then passed onto a vulnerable web application which then thinks the intrusions are genuine requests for access [31]. In 2007 OWASP [30] mentioned that most web applications are only based on automatically submitted credentials, such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials. Therefore web applications are at risk. In addition cross site request forgery has several other names: Session Riding and One-Click Attacks. All web application frameworks in 2007 were vulnerable to cross site request forgery attacks. CSRF usually takes place against a forum because it directs the user to invoke some function, such as a logged page. Attackers can force the user, without their consent, to make changes to their DSL router. The users authorisation credentials are the reason these attacks work typically the session cookie, so if the attacker could not supply credentials then the attack would fail. OWASP mentioned Cross Site Scripting (XSS) flaws which are not required to work with Cross Site Request Forgery (CSRF). Any web application with XSS flaws is retractable and vulnerable to CSRF attack because CSRF attack exploits XSS flaws for stealing any non-automatically submitted credential. Defences should be built against CSRF attack by eliminating XSS vulnerabilities in applications because XSS flaws can circumnavigate most CSRF defences. OWASP recommended verifying a web application so as to be protected from this attack by generating and then requiring some type of authorisation token that is not automatically submitted by the browser. OWASP [30] therefore contended that applications failing to use unique tokens in requests were

open to this type of attack.In the 2004 and 2007 [29, 30] versions, this type of attack is based on sending forged requests by submitting images, XSS flaws and other techniques to trick the user. Thus the attacker is able to implement and change data whilst the victim is unable to carry out permitted authorised functions. OWASP remarked that all multistep transactions are unsafe because attackers can access a series of requests by using JavaScript or multiple tags. To verify whether the application is vulnerable it should be checked. Each link and form includes tokens that help the attackers to predict a particular action detail for each user. Therefore OWASP have recommended that unique tokens be inserted per user sessions and per request, thus disabling the attackers ability to predict URL, HTML requests and user sessions details for a particular action [27]. The conclusions drawn by OWASP in 2010 [31] indicated that where the token is not unique, JavaScript or multiple tags help the attackers to exploit the web application; this helps the attackers to predict URL, HTML requests and user sessions details and acquire sensitive data. In addition, JavaScript or multiple tags that enable all multistep transactions should be considered unsafe. Recommendations Every form should have a special token [22]. Variables are filled with a good data in order to escape them [25]. Crypt ion session [1]. Use POST rather than GET [34]. Do not click any link you do not recognise because it might be used to send malicious requests to other applications the user is logged into [13]. Use browser tools, such as TG, to avoid and block any change of user authentication by the website [20]. Broken Authentication and Session Managements

VII.

Another weakness that could make ones website vulnerable is improper protection of the certification apparatus, which is described as broken authentication. Broken session management relates to functions such as logout, timeout etc. Application functions that relate to session management, if not implemented properly allow intruders to generate passwords and keys, consequently assuming the identity of the user [17]. Session management restricts the gateway to applications that use the web and information, and is authorised to shield and ideally capable of protecting administrator privileges, such as the username and password details.Organisations can demand

44

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

customised authentication, but this can lead to intruder sessions being authorised, although this can be countermanded by using built in security systems, such as SSL encryption [28]. In 2007, OWASP [30] identified flaws in the area of authentication and session management as related to the lack of session token protection in the web application. These flaws can result in privacy violations through the hijacking of the users administrative accounts. All authentication and session management web application frameworks were found to be vulnerable to this type of flaw at this time. Weaknesses usually occur with ancillary authentication functions such as logout, remember me and account update.In 2010, OWASP [31] stated that flaws within authentication and session management enable external attackers, and users who have accounts on the site, to steal information from other accounts and hide their actions. Attackers impersonate users allowing access to exposed accounts, session IDs and passwords by use of leaks in the session management functions or authentication. Recommendations Do not accept from URL, or in requests, invalid or new session identifiers. Limit or rid your code of custom cookies for authentication or session management purposes. Use simple mechanisms. and more secure authentication

VIII.

Insecure Direct Object References

These flaws resulted from developer error that exposes a direct object reference such as a database, key or directory. A direct object reference can occur when a developer leaves access to an object on the server such as a data file or database key. This can be countered by means of an authorisation check; if not performed this can enable intruders to alter references to these files causing havoc to these systems [31]. When authorisation checks have been restricted or even stopped this vulnerability can appear. Where programmers usually use object references directly in web interface, with no validation checks. Insecure Direct Object Reference allows an attacker to access other objects in the web application without authorization by manipulating direct object references. Furthermore, this type of attack occurs when there is exposure of reference, i.e. a database record as well as form parameter or URL in an internal implementation object. OWASP [30] mentioned flaws that can occur when a direct object reference, such as a URL or form parameter and database record is exposed by a developer. An attacker could access the object through manipulation of direct object references, unless an access control check has been put in place without authorization. OWASP also mentioned that many applications expose internal object references to users, enabling attackers through use of parameter tampering, to violate access control policy by changing the references. In 2010, OWASP [31] mentioned flaws that occur when developers expose references that take place within an internal implementation object such as database key, directory and files to the user. The attacker can therefore gain access to unauthorized data through manipulation of references, due to absence of protection or access control checks.The reason for the continuation of these flaws in the web applications relates to the fact that many applications which create web pages utilize the actual name or key of an object and do not verify the user is authorized for the target object. Recommendations Do not expose private object references to users. Validate any private object references. Verify authorization to all referenced objects. Verify from input that might include attack patterns [21]. IX. Insecure Communications

Use a strong password policy. Enable login process from an encrypted page. Make sure all client side cookies and server side session state are destroyed on logout. Users should enter their old password when changing to a new password. Use limited-time-only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Beware self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change [21]. Avoid authentication and session management manipulation by the user to pass security control [17].

OWASP highlighted the need to protect sensitive communication because this will allow media sensitive data to be exposed. Applications often fail to encrypt network traffic

45

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

that expose an authentication or session token. Therefore encryption should be used for all authenticated connections and web pages that are accessible.All web application frameworks mentioned by OWASP, are vulnerable to this flaw. Such deficiencies enable the attacker to sniffer network traffic and gain access or capture sensitive and important information, including transmitted credentials or conversations, since every single request can contain a session token or authentication credential [30].Security breaches are also possible when Insecure Communications occur when the web application does not have encryption for all authenticated connections and sensitive data [21]. Recommendations Use SSL for all connections that are authenticated or transmitting sensitive or value data. Protect communications between infrastructure elements by using protocol level encryption or transport layer security [21]. Encrypt data. X. Failure to Restrict URL Access

checks are performed before request to access a sensitive function is granted. Recommendations Design of the application and architecture should include access control matrix. An effective access control mechanism to protect all URL and business functions. Make a penetration test for the application to ensure application security. Make sure that administration is protected [21]. XI. Insufficient Transport Layer Protection

Insufficient Transport Layer Protection allows an attacker to steal sensitive data or set access to the web application, due to vulnerability exposing communication [3]. This arise using expired, invalid or incorrect certificates which lead to applications failing to protect network traffic. These flaws are very dangerous because the application does not use SSL/TLS elsewhere during authentication so it might expose sensitive data; i.e. session IDs of users, leading to account theft [31]. Recommendations

According to Kategorileri [21], Failure to Restrict URL Access occurs as result of a lack of access control checks. This is because the web application usually protects an URL to avoid the page presenting links to unauthorized users.Web access to internet addresses or URLs is checked before any images or buttons on the page appear; this requires web applications to perform checks every time these pages are viewed, or intruders will be able to gain access by forging their URL addresses. Tools such as these cannot identify whether the page is accessible to the user, and therefore it is difficult to identify whether an issue exists with access [31] Scanners are tools that can be used to find hidden URLs, but they are unable to determine whether these functions or pages are to be protected by any controls or restrictions. In order to find these hidden pages they use a number of methods such as fuzzing directory and file names, directory lists, and also trying to find backup and file folders. This form of attack is called forced browsing and contained guessing links and brute force techniques to find unprotected pages [30]. This can result in applications which allow access for control code to develop into a complex model for developers and security specialists to understand. In 2010 OWASP [31] identified further serious threats to web applications being that anyone can send a request to a web application and therefore gain access to the network. Certain applications do not protect page requests correctly; i.e. no

Use strong algorithms. Use SSL for all sensitive pages in the applications. Use encryption technologies or SSL with backend and other connections. Make sure the server certificate has not expired or been revoked [4].

XII.

CONCLUSIONS

This paper presents and discusses ten web application vulnerabilities, Injection Flaw, Cross-Site Scripting (XSS), Buffer Overflow, Insecure Cryptographic Storage, Cross Site Request Forgery (CSRF), Broken Authentication and Session Managements, Insecure Direct Object References, Insecure Communications, Failure to Restrict URL Access and Insufficient Transport Layer Protection. Detailing the researchers opinions and OWASP regarding risk assessment and protection. As aadopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within organization into one that produces secure code the paper provides some recommendation for adapting these ten web application vulnerabilities.

46

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

REFERENCES
[1]. [2]. [3]. [4]. Alameda, A. (2008). Foundation Rails 2. United States of America: Springer-Verlag New York, Inc, pp387-388. Alqahtani, A. A. (2010) Security and Protection Information in Modern Web Application. Available from: http://coeia.edu.sa [Accessed 07/07/2010]. Auger, R. (2010). Insufficient Transport Layer Protection. Available from: http://projects.webappsec.org/InsufficientTransport-Layer-Protection [Accessed 3/09/2010]. AUUGN (2005) The Conference for Unix, Linux and Open Source Professionals. Available from: http://books.google.co.uk/books?id=iJw5zAu7LncC&prints ec=frontcover&dq=AUUGN&hl=en&ei=HvKPTNfSE9CH 4AbD3oyPDg&sa=X&oi=book_result&ct=result&resnum= 1&ved=0CCoQ6AEwAA#v=onepage&q&f=false [Accessed 25/08/2010]. Belapurkar, A. et al. (2009). Distributed systems security: issues, processes, and solutions. United Kingdom: John Wiley & Sons Ltd, pp105-106. Boyd, C. and Mao, W. (2003). Information security: 6th international conference, ISC 2003, Bristol, UK, October 1-3, 2003: proceedings, Volume 2851. Germany: SpringerVerlag Berlin Heidelberg New York, P367. Carey, M. et al. (2008). Nessus network auditing. United States of America: Andrew Williams, p1. Clarke, J. (2009) SQL Injection Attacks and Defense. USA: Syngress Publishing, Inc. Cole, E. (2002). Hackers beware. United Stated of America: New Riders Publishing, p248. Cumming, A and Russell, G. (2007) SQL Hacks. USA: OReilly Media, Inc. Ciampa, M. (2008). Security+ Guide to Network Security Fundamentals. 3rd ed. Canada: Cengage Learning, p85. Dubrawsky, I. (2009). CompTIA Security+: Exam SYO 201, Study Guide and Prep Kit. United States of America: LanraColantoni, pp109-110. Dwivedi, H. and Clark, C. and Thiel, D. (2010). Mobile Application Security. Unite States of America: The McGraw-Hill Companies, pp7-266. Flanagan, D. (2006). JavaScript: the definitive guide. 5th ed. United States of America: O'Reilly Media, Inc, pp267268. Ford, R. (2007). Infosecurity 2008 threat analysis. United States of America: Arnorette Pedersen. Gama, J and Naughter, P. (2006) Super System: Turbocharge Database Performance. US: Rampant Teach Press, Kittrell, NC, USA. Gregory, P. (2009). CISSP Guide to Security Essentials. United States of America: Cengage Learning, p99. Grossman, J. and Hansen, R. (2007). XSS attacks: crosssite scripting exploits and defense. United States of America: Syngress Publishing, Inc. Holovaty, A. and Kaplan-Moss, J. (2009). The Definitive Guide to Django: Web Development Done Right. United States of America: Springer-Verlag New York, Inc, p345. Jakobsson, M. and Ramzan, Z. (2008). Crimeware: understanding new attacks and defenses. United Kingdom: Symantec Press, p156. Kategorileri, Y. (2008). OWASP Top Ten 2007 Most Critical Web Application Security Vulnerabilities .Available from: [22]. [23]. [24].

[25]. [26]. [27].

[5]. [6].

[28].

[7]. [8]. [9]. [10]. [11]. [12]. [13]. [14]. [15]. [16]. [17]. [18]. [19]. [20]. [21].

[29]. [30].

[31].

[32]. [33]. [34]. [35].

http://serdarbuyuktemiz.blogspot.com/2008/09/owasp-topten-2007-most-critical-web.html. [Accessed 29/08/2010]. Laurent, S.S. and Dumbill, E. (2007). Learning Rails. United States of America: O'Reilly Media, Inc. Lee, W. (2009). Windows 7: Up and Running: A Quick, Hands-On Introduction. United States of America: O'Reilly Media, Inc, p129. Lpez, J. and Bernhard M. Hmmerli (2008). Critical Information Infrastructures Security: Second International Workshop, CRITIS 2007, Benalmadena-Costa, Spain, October 3-5, 2007. Germany: Springer-Verlag Berlin Heidelberg, p288. Makice, K. (2009). Twitter API: up and running. United States of America: O'Reilly Media, Inc, pp98-99. McClure, S. and Scambray, J. and Kurtz, G. (2009). Hacking exposed 6: network security secrets & solutions. United States of America: McGraw-Hill Companies, p592. Mike Andrews, James A. Whittaker, J.A. (2006). How to break Web software: functional and security testing of Web applications and Web services, Volume 1. US: Pearson Education, Inc, pp66-67. S. (2007) CIO. Available from: Overby, http://books.google.co.uk/books?id=1woAAAAAMBAJ&p g=PA68&dq=prevent+Broken+authentication+ans+session +management&hl=en&ei=_TB7TKCUF5GSswbomOSyD Q&sa=X&oi=book_result&ct=result&resnum=7&ved=0C FYEwBg#v=onepage&q&f=false [Accessed 28/08/2010]. OWSAP (2004) The Ten Most Critical Web Application Security Vulnerabilities. Available from: http://ftp.ipv4.heanet.ie/ OWSAP (2007)The Ten Most Critical Web Application Security Vulnerabilities. Available from: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007 .pdf [Accessed 26/06/2010]. OWSAP (2010) The Ten Most Critical Web Application Security Vulnerabilities. Available from: http://owasptop10.googlecode.com/files/OWASP%20Top %2010%20-%202010.pdf [Accessed 26/06/2010]. Peikari, C. And Chuvakin,A. (2004). Security warrior . United States of America: O'Reilly Media, Inc, p167. Powell, T.A. (2008). Ajax: the complete reference. unite States of America: The McGraw-Hill Companies, p322. Shiflett, C. (2005). Essential PHP security. United States of America: O'Reilly Media, Inc, pp26-245. Wells, C. (2007). Securing Ajax applications. United States of America: O'Reilly Media, Inc, p51.
AUTHORS PROFILE

Fahad Alanazi is a PhD student in De Montfort University. Faculty of Technology.Software Technology Research Laboratory (STRL). He received his B.Sc in computer science from Tabouk University in Saudi Arabia and also received MSc in Computer Security from De Montfort University. His main research interests are Computer security and Computer forensic. Dr. Mohamed Sarrab his Ph.D. degree in Computer Science from De Montfort University 2011. He received his B.Sc in computer science from 7th April University Libya and also received M.Sc in Computer Science from VSB Technical University of Ostrava Czech Republic. His main research interests are Computer security, Runtime Verification, Computer forensic.

47

http://sites.google.com/site/ijcsis/ ISSN 1947-5500