Evolution of Web Security - Essay Example

Web Security Prepared for Web Security Introduction Technological evolution has grownfast and vast. Its impact in the organisational and individual’s daily operations is intense. Business industry, government and other organisation have increasingly employed web platform information systems as a means of delivering and doing business. They have done so to harness the benefits internet and web platforms provide. However, these platforms are loaded with a major risk: information security risk. In the recent years, web security, a branch of information security has drawn an eye of attention from many industries and organisations. This is because websites, web applications and web services, all being components of web security, create integral part of the daily operations of these industries and organisations. Information sharing or business or service delivery of these organisations now faces a lot of dangers. From invasion of their privacy, information theft, sabotage, black mailing to compromising corporate operation and end user activities. Web security analysis by various stakeholders has established that the web security threats typically result from mistakes in coding or programming the website, poor input and output sanitisation of a website. These mistakes have left a hole exploited by the hackers’ community to launch attacks on websites. The security of the web application, underlying operating system and computer network is at risk. The existence of exploit paths on a web system and the magnitude of that exploit path can be evaluated continuously to assess the risk level to the business. The type of web attack launched by hackers depends on many factors. Most factors are unique to the web attack as will be discussed in this essay. The essay will also examines the nature of these web attacks, details of their vulnerabilities, the risk levels they may raise and how to control or reduce the risk web attacks poses to organisational information and business operations. Web Security Threats Web security risks in the name of defaced, hacked or web broken into have increased with the significant increase of the internet usage. A threat is anything that causes worry or fear, especially, because of the events there after (Consequences). Web security threats are increasing and causing big fear in organisations or individuals. According to Stuttard and Pinto (2008), the most serious attacks against web application are those that expose sensitive data or gain unrestricted access to the backend systems on which the application is running. Apparently, the total number of reported web defacement remains miniscule in comparison to the total number existing web sites. The rapidly growing risks raises concern to many businesses, individuals and security professional. Below are major web security threats. 1. SQL Injection Website applications are majorly database driven, meaning, they operate by querying and executing database commands at the back-end or webserver. The universal database programming language for most of this web databases is SQL-Structured Query Language. Using web application programming languages like ASP, JSP, PHP, CGI, etc. in collaboration with SQL to design web applications presents a web security vulnerability termed SQL injection. Attackers (inject) database SQL commands by tricking the web server to execute and expose the back-end database. This comes as a result of poor sanitation or improper validation of data that is being submitted as part of the query command. The intention of such an injection is actually to trick into executing unintended commands or alter data without verified authenticity. The vulnerability more emerges with the ability of creating SQL strings on the fly and then running them at the database end. With that hacker can create really surprises to the databases and in a short period a website is defaced. The nature of SQL injection presents an entirely complex vulnerability since the attacker can create, update, read, alter, delete or restructure database. One can only image a disaster of exploiting credit card numbers or even security numbers. For such an exploit to occur, attackers craft a special input and inject it into your web page form inputs or URL. This creates a flow in the query command such that the database interpreter is not able to distinguish unintended commands and the crafted input. This smoothly tricks to execute in favour of their intention. This execution occurs at the database layer of the web site. The clue of vulnerability lies in the existence of forms on the website. Actually, anything that lies between the is a potential exploit parameter in any given website. For the websites developed in PHP, CGI, ASP, JSP and others a URL that use parameters can be challenged. An example is http://mycybertest.php?id=110. This URL can be turned into an exploit by injecting some data in the parameter list as explained next. At the database layer, the command interpreter understands some characters to mean some function. Starting with the single quote character (‘) or the two hyphens (--) characters, an SQL injection exploit is ready to launch. Using an ASP web page and SQL back-end an exploit will be carried as follows. An attacker who wants to trick the website to display extra information that is not normally available will look at URL like http://mycybertest/index.asp?category=broker. Straight from a programmers view Category is a variable name and broker is a value assigned to that variable. He then anticipates that the underlying code will be like: cat = request("category") ‘ receive category into variable cat sqlstr="SELECT * FROM members WHERE _Category=" & cat & "" set rs=conn.execute(sqlstr) ‘ executing the query This will entirely result with an SQL statement SELECT * FROM members WHERE _Category=broker. The ‘WHERE CLAUSE’ is meant to return one or more rows that meet the condition but in there is where the room of exploit lies, that is after the equal sign. Inside the URL the user only needs to change it to appear as http://mycybertest/index.asp?category= broker or 1=1- - and the result query is SELECT * FROM members WHERE _Category=broker or 1=1--. What follows next from such an injection is disaster, 1=1 is true and the use of OR evaluates the query successfully. The table is going to select everything from the table because the condition has been altered to evaluate successfully. The database interpreter is already tricked and exploited. Preventing SQL Injection SQL injection can be prevented by sanitising and validating the inputs before creating a query at fly. Some of these methods include: 1. Use safe APIs that offer strongly typed parameterized query 2. Employ careful escape special characters using the particular escape syntax for the interpreter 3. It is more advisable to use stored procedure as they little safer but not entirely 4. Adopt an input validation that is defined against business rules like length of characters, syntax or type. 2. Cross Site Scripting (XSS) Apart from SQL injection discussed above, attackers can penetrate a website using scripts they have re-programmed or programmed. Cross Site Scripting differs from SQL injection in the sense that, instead using queries as user inputs, the attackers inject code form the client side to the remote server to launch an exploit. XSS attackers can simply manage to insert rogue script of either JavaScript or other scripting language in the target pages. This code is then executed in the context of the browser as origin with a defined domain, protocol and port number. This type of hacking actually occurs at the application layer of a website and not like the previous that occurs at the database layer. At the application layer, XSS leverages vulnerabilities in the web application code to allow an attacker to send malicious script from the client side and collect some type of data from the back-end. Cross Site Scripting lies in a number of vulnerabilities. Attackers can use a script to get website user accounts by hijacking sessions or simply tricking the users to type username and password into a theft form and submitting it to the attackers. Attackers also use XSS to infringe privacy of website visitors by tracking the browsing behaviour. They can also use keystroke logging and abuse credentials and trust of a website. The main target of attackers normally ranges from data theft, site defacement, vandalism, link injections and content theft. All this a hacker can achieve using cross site scripting. XSS attacks are grouped into persisted and non-persistent. Non-persistent tricks a user to visit a specially crafted link by the attacker. On the user, clicking and visiting the link, crafted code is executed by the user’s browser and could do malicious events. Using a PHP script for example an attacker can craft a link at an index.php as follows. Also in the $name = $_GET[name]; expression lies a potential exploit such that the index URL will be injected with some JavaScript like index.php?name=guestalert(attacked) . Placing a JavaScript code of any malicious nature in the URL will launch an exploit. Such an injection like index.php?name=window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";} will redirect the visitor to not-real-xssattackexamples.com and there they will submit credential thinking they working with the right people. Attackers who want to avoid raising an alarm will then encode the ASCII to hex and get away with it silently. The victims will visit the website without knowing what it is and non-persistent XSS attack would have occurred. Persistent XSS attacks are destructive when compared to non-persistent. Here the attackers store the attack script in a database or storage device. They then use tactics to hijack user’s sessions using the scripts performed. The introduction of sessions was meant to bridge the gap of protocols not having a state when conducting request and response activities of a network. Sessions were to maintain some state between the browser and the web server so that not to bother the user for username and password anytime a request is made. So the user logs in once and a session ID is created in the server. The session becomes XSS exploit position for an attacker targeting a website. Consider a website where there are two user types: Admin and ordinary users. When an admin logs into the website he gains a privileged access including listing of the ordinary usernames. However, the ordinary user can only update their username and have limited authority. Now the code at the server side that creates a session cookie will look like this. $query="SELECT user_name,password from $Schema.members where user_name=".$_POST[user_name].";"; $result=pg_query($Connect,$query); //connects to database $row=pg_fetch_array($result,NULL,PGSQL_ASSOC); //fetches a table $user_pass = md5($_POST[pass_word]); //encrypts password and assign it variable $user_name = $row[user_name];// assign username //test if credentials are right it creates session cookies if(strcmp($user_pass,$row[password])!=0) { echo "Login failed"; } else { # Start the session session_start(); $_SESSION[USER_NAME] = $user_name; echo " "; } And at the home page the code that will be used to enforce sessions will be as follows session_start(); if(!$_SESSION[USER_NAME]) { echo "Need to login"; } else { if($_SERVER[REQUEST_METHOD] == "POST") { //update user $query="update $Schema.members set display_name=".$_POST[disp_name]." where user_name=".$_SESSION[USER_NAME].";"; pg_query($Connect,$query); // connect to database echo "Update Success"; } else { if(strcmp($_SESSION[USER_NAME],admin)==0) { //log in as admin echo "Welcome admin
"; echo "List of users are
"; //list all user $query = "select display_name from $Schema.members where user_name!=admin"; $res = pg_query($Connect,$query); while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC)) { echo "$row[display_name]
"; } } else { //if the session is set then display the update link echo ""; echo "Update display name:"; echo ""; …… Well the attacker now needs to only log in as an ordinary user and then in text input of display name he or she enters a script of this nature. My Name and submit the information which will be stored in the database. The net is set, all that is left is the bad to fly into the net and the exploit is done. When the admin will log into the system, a link with the text “my name” along with other details will be displayed. If the admin clicks on this link, it will send the cookie which has a session ID to the attacker’s site. Attacker can then manipulate and post request to the webserver and act as admin until the session expires. Within that period an attacker can take over the website, deface it or steal information. Preventing XSS According to the Open Web Application Security Project (2010), there are a number of ways a website can prevent XSS. They include: 1. Avoid placing untrusted data in allowed locations like nesting URL inside JavaScript makes encoding rules tricky to implement 2. Use the HTML escape when placing untrusted data into HTML element content 3. Use attribute escape before inserting untrusted data into HTML Common attributes 4. Escape dynamically generated JavaScript before inserting untrusted Data into JavaScript Data values. 5. Perform a CSS escape and strict validation before inserting untrusted data into HTML property values. 3. Broken Authentication and session management This web attack is closely related to the XSS but is unique in its on nature. With the aspect of trying to secure the information on the websites, developers use passwords and usernames to authenticate users to access web services. However, they face a challenge in that HTTP provides no capability to continuously monitor the activities. So developers develop this mechanism into their website using session tokens and heighten the security with them. The use of session token itself presents an exploit opportunity if not well protected. Attackers can hijack active session token and take over control of a website. The most worrying point is that creating highly protected session token has proven difficult to most web developers. The authentication mechanism web developer create can be compromised by hackers by use of flawed credential management functions. This function include forgot my password link or remember password link, password change and account update. Once the attackers discover this exploit, an organisations data and information is a few steps away from being compromised. This type of attack actually can cause an organisation’s business to come to a standstill. Assuming that an organisation runs an online web application and the attackers has compromised the web servers. Business will halt and big losses can incur including loss of critical data and bridge of privacy. Broken authentication and session management issues affect almost all layers: application servers, web servers and web application. Implementing a strict mechanism that protects the session identifies will at least safe an organisation from the siege this attack can bring. The attackers find vulnerability spots in many areas some including lack of hashing or encryption to protect log on credentials. The possibility of guessing user credential or weak account management, expose of session ID in the URL, handling of the session timeout and destroying of a session are some of the areas that attackers can use to penetrate a web application. Given a website that uses HTML forms as means to authenticate users in accessing web services, an attacker can see the code of the website using the browser as follows: The attacker now can be sure that using dubious mechanisms he can bypass the authentication system by spoofing. Trying to guess and replaying the authentication information with some series of different tokens can either render an accidental successful log or consecutive unsuccessful log. However, with unsuccessful, the attacker will gain a new knowledge for his action – the measure of session inactivity and timeout. With such knowledge, an attacker can use different mechanisms to cheat the website security system. Attackers can use brute force cracking to gain access past a web security mechanism. It uses sheer programming styles and computing powers to try all possibilities of getting a successful solution to gain access by guessing username and password. Dictionary attacks also uses programming scripts engineered to try and guess thousands of usernames and passwords from a dictionary file. The dictionary can use an attacker defined pattern to guess this usernames and password. If all the above is unsuccessful the attackers turn to the authentication mechanism and break their way in. Consider an example where the attacker, using an existing and legal account in the system, log into the web application legally. After logging the attacker will have been issued a session ID by the web application and can use an XSS script to random trap the session ID with the target server. Using session fixation the attacker now will try to transport the trap session ID (say 1234) to a victim’s users browser. This can be done through cheating the user to click an embedded link that will log him or her into the webserver. Example is http://online.onlinebank.com/login.jsp?session=1234, attackers will encode this URL to avoiding raising alarm. Another option attackers will employ through this web attack is the use of session ID in a hidden form field. They simply create a look-alike website with a login form that is similar with that of target website and user will submit this data in a hidden input. They can also use cookies or resolve to cross site scripting at advanced level. Preventing broken authentication and session management Session management and authentication mechanism protection has proven complex and elusive to many of developers to control. However, developers can protect system by trying to implement some basic techniques to help the situation. The following can help curb this web attack: 1. Utilizing SSL for all authentication parts of a web application could provide protection. 2. Avoiding the use of home grown cookies for session management or authentication 3. Eliminating the use of login process from an unencrypted page 4. Ensure always that all credentials are stored in a hashed form 5. Immediately a user logs in invalidate any of their previous session cookie and create them a new cookie. 6. Avoid sending user credentials over insecure channels like email 7. Ensure that each page has a logout link that is visible and identifiable to the user 8. Allocate shortest time timeouts for inactive sessions. 9. Do not expose session tokens inside the URL 10. On account update ensure that users submit old password before changing their passwords Conclusion Web security is a very important area of information technology. With the majority of users and organisation increasingly using web application to sale, buy, promote, inquire or even market online, there is need to protect websites from defacement. The motive of an attacker varies but the result will be sabotage, loss of information, infringement of data privacy, money loss through credit card number theft and others. Protecting web application is now a need for any organisation that has an online presence. Understanding each web attack, how it is carried out, and how to prevent the attack is the best way forward. This essay examined three web attacks: SQL injection, XSS and Broken Authentication and session management. Although no one can stop web attacks permanently, the prevention recommendations given for each can help reduce the menace the attacks can cost an organisation or individual. References STUTTARD, D., & PINTO, M. (2008). The web application hackers handbook discovering and exploiting security flaws. Indianapolis, IN, Wiley Pub. http://www.books24x7.com/marc.asp?bookid=23460. THE OWASP. (2013). Open Web Application Security Project. [Online] Available: https://www.owasp.org/index.php/Top_10_2013 [17th March 2013]. Read More

 

Read More