Security Concerns In Web Services Development Up To Web 3.0 Essay

As a large and complex application platform, World Wide Web is able to offer a wide range of sophisticated applications. However, many web applications go through phases of rapid development with extremely short response times, which makes it difficult to eliminate vulnerabilities. Here we analyze the design of security assessment mechanisms for web applications to identify poor coding practices that make web applications vulnerable to attacks such as SQL injection and cross-site scripting. We describe the use of several software testing techniques (including black box tests, fault injection) and some new techniques based on machine learning, which are called the Learning Protection Mechanism, which can be implemented in web 3.0 to 4.0 as smart web Security itself detects malicious activities that enter the system and tries to stop them immediately.

The Web has become a platform for supporting a wide range of criminal enterprises such as spam-advertised commerce (e.g., counterfeit watches or pharmaceuticals), financial fraud (e.g., via phishing or 419-type of frauds) and as a vector for propagating malware (e.g., so-called ‘drive-by downloads’). Although the precise commercial motivations behind these schemes may differ, the common thread among them is the requirement that unsuspecting users visit their sites. These visits can be driven by email, Web search results or links from other Web pages, but all require the user to take some action, such as clicking, that specifies the desired Uniform Resource Locator (URL).Clearly, if one could inform users beforehand that a particular URL was dangerous to visit, much of this problem could be alleviated. To this end, the security community has responded by developing blacklisting services — encapsulated in toolbars, appliances and search engines — that provide precisely this feedback. A range of techniques including manual reporting, honeypots, and Web crawlers combined with site analysis heuristics in turn constructs these blacklists. Inevitably, many malicious sites are not blacklisted either because they are too new, were never evaluated, or were evaluated incorrectly (e.g., due to “cloaking”). To address this problem, some client-side systems analyze the content or behavior of a Web site as it is visited. But, in addition to run-time overhead, these approaches can expose the user to the very browser-based vulnerabilities that we seek to avoid.

Detecting web application vulnerabilities

We chose SQL injection and cross-site scripting vulnerabilities as our primary detection targets for two reasons: a) They exist in many Web applications, and b) Their avoidance and detection are still considered difficult. Here we will give a brief description of each vulnerability, followed by our proposed detection models.

Injections are one of the most common this that happen in a PHP application. The idea of this concept is that the person who tries to breach the security of our application has to make an educational guess about your database schema. This method requires a lot of experience because a normal person cannot make the exact guess about your database schema. To understand this concept let’s take a simple example. In this example, we can see that the attacker can see the username and password in the HTML code, from there the attacker can make a rough guess about the database table. Of course, the attacker might not guess it on his first try but after some experimentation, he might guess it. We use a method to encrypt our password, which we call MD5 algorithm, which is commonly used, but it is not a good method to encrypt your data. Recent discoveries have revealed both weaknesses in the MD5 algorithm so use another method to encrypt your data which can encrypt and decrepit you data as well.Example: Using the code from our running example, we illustrate two ways in which Inference based attacks can be used. The first one is to identify the injectable parameters by blind injection. Consider two possible injections in the login field. The first one is “Legal User” and 1 = 0 – – “and the second,” Legal User “and 1 = 1 – -“.

Now, let’s consider two scenarios. In the first scenario, we have a secure application and the login for the login is validated correctly. In this case, both injections would return the login error messages, and the attacker would know that the login parameter is not vulnerable. In the second scenario, we have an insecure application and the login parameter is vulnerable to injection. The attacker sends the first injection and, as always evaluated as false, the application returns a login error message. At this point, however, the attacker does not know if this is because the application validated the entry correctly and blocked the attack attempt or because the attack itself caused the login failure. The attacker then sends the second query, which is always evaluated as true. If in this case there is not a login error message, then the attacker knows that the attack was made and that the login parameter is vulnerable to injection.

Cross-Site Scripting

Cross-site Scripting (XSS) refers to the client-side code injection attack in which an attacker can execute malicious scripts (also known as malicious uploads) on a legitimate website or web application. XSS is among the most unbridled vulnerabilities in web applications and occurs when a web application uses an invalid or coded user entry within the output it generates. By taking advantage of XSS, an attacker does not directly attack a victim. Instead, an attacker could exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser. While XSS can be exploited within VBScript, ActiveX and Flash (although it is now considered inherited or even obsolete), unquestionably, the most abused is JavaScript, mainly because JavaScript is essential for most browsing experiences.

Privation of SQL injections and XSS attacks

Black Box Testing

Huang and colleagues propose WAVES, a black-box technique for testing Web applications for SQL injection vulnerabilities. The technique uses a Web crawler to identify all points in a Web application that can be used to inject SQLIAs. It then builds attacks that target such points based on a specified list of patterns and attack techniques. WAVES then monitors the application’s response to the attacks and uses machine-learning techniques to improve its attack methodology. This technique improves over most penetration-testing techniques by using machine-learning approaches to guide its testing. However, like all black box and penetration testing techniques, it cannot provide guarantees of completeness. The combination of such privation mechanism and machine learning is very efficient to detect and block any malicious activities into the system.

Combined Static and Dynamic Analysis

AMNESIA is a model-based technique that combines static analysis and runtime monitoring. In its static phase, AMNESIA uses static analysis to build models of the different types of queries an application can legally generate at each point of access to the database. In its dynamic phase, AMNESIA intercepts all queries before they are sent to the database and checks each query against the statically built models. Queries that violate the model are identified as SQLIAs and prevented from executing on the database. In their evaluation, the authors have shown that this technique performs well against SQLIAs. The primary limitation of this technique is that its success is dependent on the accuracy of its static analysis for building query models. Certain types of code obfuscation or query development techniques could make this step less precise and result in both false positives and false negatives. Similarly, two recent related approaches, SQLGuard and SQLCheck also check queries at runtime to see if they conform to a model of expected queries. In these approaches, the model is expressed as a grammar that only accepts legal queries. In SQLGuard, the model is deduced at runtime by examining the structure of the query before and after the addition of user-input. In SQLCheck, the model is specified independently by the developer. Both approaches use a secret key to delimit user input during parsing by the runtime checker, so security of the approach is dependent on attackers not being able to discover the key. Additionally, the use of these two approaches requires the developer to either rewrite code to use a special intermediate library or manually insert special markers into the code where user input is added to a dynamically generated query.

Privation of SQL injections with machine learning

Architecture of the System

The detection module is in front of web server, and it captures HTTP requests from clients and reviews these requests to prevent any malicious SQL query Detection system. Monitor is responsible for capturing and decoding the parameters of HTTP requests from clients. After capturing parameters of each HTTP request, these parameters are converted into numeric attributes by Converter. Classifier estimates the class of each parameter and makes further appropriate processes. The machine learning approach in detecting and blocking SQL Injections into the system is efficient way to minimize the attacks and making the database secure from malware.

Classifier

Classifier is to determine each pattern’s class with Bayesian classifier. Bayesian classifier is based on Bayes’ decision theory. It uses Bayes’ equation to calculate the probability of each class of an object, and then choose the one that has larger posterior probability as the object’ class. The principle of Bayesian classifier is given in Figure 4.2.1.The attributes of each sample are served as the parameters of discriminate function hi(X). Discriminate functions calculate the probabilities based on Bayes’ equation, which can be express as P(X|w1)P(w1). Through comparing the results of discriminate functions, Classifier calculates the maximum value, and further gets the most possible class of a pattern and calls the corresponding processes.

In this algorithm, Classifier calculates two probabilities of a pattern by discriminate functions, including the probability of the injection pattern and the probability of the legitimate string, and then gets the most probable class of this pattern. Classifier executes next processes according to this result. If the pattern is a SQL injection code, it will sound a warning and write this pattern into the injection log file and execute the block process to terminate the connection. If the pattern is a legitimate string, it will write this string into the legal log and let it pass through.

Related work

Various techniques have been proposed for the confrontation of the threat of SQL injection attacks. In this section, the characteristics of the best-known techniques are briefly discussed and their principal weaknesses are highlighted.

Conclusion and future work

This article presents a novel methodology for the detection of SQL injection attacks. According to the approach, a specification describes the intended structure of the SQL queries that are produced by the web application. An SQL query is considered a security violation if it does not conform to the pre-defined query specification rules.

We developed an idea to control this kind of attacks and removing vulnerabilities into the web applications through machine learning as a modern approach as human cannot differ these things as correct as a machine can and in a number of traffic is coming.

In the future, we plan to carry out more experiments to verify that -as it might be expected- the behavior of the new method is not affected by the application scenario and characteristics. An issue that also requires extensive future research is the comparison of the proposed method against existing detection methods under a common and flexible benchmarking environment. Finally, attempts should be made to modulate the proposed technique so that it might detect other types of code injection attacks and other types of attacks that offend web applications and on-line databases.

How to cite this essay: