SQLI Attack: Attack Prevention Techniques for SQL Injection

ABSTRACT:

This article speaks about the improvement in the development process of the application to avoid the SQLIA attack at the preliminary level, especially at the source code itself. We discuss about the possible methods to attack an SQLIA providing the pseudo code for better understanding. A prototype of the solution i.e. consolidating the validation into a single custom component termed as Injection Box control (IBC) that takes care of all the possible preventive measures for controlling the SQLIA at the source code level itself.

Keywords: SQL rand, Sql injection vulnerabilities, Sql injection attack prevention.

1. INTRODUCTION

Web applications enable much of today’s online business including online banking, online shopping, and online university admissions and various online governmental activities. Anyone can use a web browser and can access them, and the data they manage typically has significant value both to the users and to the service providers. [1, 2, 3, 4, 5 and 6] The standard language for accessing database servers including MySQL, Oracle, and SQL Server is SQL (Standard Query Language). Web programming languages such as java and asp.net provide various methods for constructing and executing SQL statements, but developers often misuse these methods due to lack of training and development experience and resultant occurs as SQL injection vulnerabilities. To construct SQL statement the developers usually use the dynamic query building with string concatenation. [7, 8, 9, 10, 11 and 12 ] The system forms queries with inputs directly received from the external sources, during runtime. This method makes it possible to build different queries based on varying conditions set by the user.

However, as this is the cause of many sql injection vulnerabilities. Consequently, vulnerabilities that allow an attacker to compromise a web application’s control of its data pose a significant threat. SQL command injection vulnerabilities comprise most of this class.

A sql injection [SqlI] attack occurs when a malicious user, through specially crafted input causes a web application to generate and send a query that send a query that functions differently than the intended programmer.

For example, if a database contains user names and passwords, the application might have code such as the following:

Query = "select * from accnt where name='"

+ request.getParameter("name")

+ "' and password='"

+ request.getParameter("pass") + "'";

This code generates a query intended to be used to authenticate a user who tries to login to a web site. However, if a malicious user enters guy into the name field and.’OR' a'='a. into the password, the query string becomes:

Select * from accnt where

Name ='guy' and password='' or 'a'='a' this condition always evaluates to true.

2. Existing Issues

Though client side input validation happens, never trust that, since it can be evaded easily i.e. hacker will simply watch the return value and changes it as he needs[1].Although we have many tools to identify SQLI vulnerables, research show that only 20 percent of the vulnerables are revealed while a scan is run. Out of the alarms raised by the tools 50 percent of them are false alarms [3].Experts suggest that using prepared statements, stored procedures in the code can avoid injection, but it is found that string concatenation while framing a dynamic query can cause SQLIA to the system.

3. Related works

Fault injection techniques have traditionally been used to inject physical (i.e., hardware) faults [18], [19]. In fact, initial fault injection techniques used hardware-based approaches such as pin-level injection or heavy-ion radiation. The increasing complexity of systems has lead to the replacement of hardware-based techniques by software implemented fault injection (SWIFI), in which hardware faults are emulated by software. Xception [20] and NFTAPE [21] are examples of SWIFI tools.

The injection of realistic software faults (i.e., software bugs) has been absent from fault injection effort for a long time. First proposals were based on ad-hoc code mutations [22], [23], but more recent works focus on the injection of

representative software faults based on comprehensive field studies on the most common types of software bugs [24].

The use of fault injection techniques to assess security is actually a particular case of software fault injection, focused on software faults that represent security vulnerabilities or may cause the system to fail in avoiding a security attack. Neves et al. proposed an Attack Injector

Tool (AJECT) to support the discovery of vulnerabilities in network servers, specifically IMAP servers [25].

To attack the target system they used predefined test classes of attacks and some sort of fuzzing. Our approach automatically discovers places in the web application code that can be used to inject vulnerabilities using fault injection techniques and smart fuzzing to seamlessly attack them.

It is shown that weak typed languages are more prone to SQLI vulnerables than the strong typed languages [1]. 76 percent of the SQLI vulnerables are related to the multiple function call extended (MFCE). The commercially used scanners are unable to detect most of the vulnerables injected via Vulnerability Attack Injector Tool (VAIT). Despite some of them seemed to be apparently easy to detect. This shows that there is always a room for improvement in detecting vulnerables by the scanner [4].

The industry uses fuzzing and mutation testing to automate penetration testing of web applications. They rely on web application vulnerability scanner tools that also generate reports compliant with security regulations (Sarbanes-Oxley, PCI-DSS, etc.). Some of the best known

of such tools are HP WebInspect, IBM Watchfire AppScan, Acunetix web application security scanner and Web- Sphinx. In spite of their continuous development, these tools still have many problems related to the high number of undetected vulnerabilities and high percentage of false positives, as shown by several studies [26], [27]. To address these problems, it was proposed a method to benchmark these scanners [26]. The method starts by identifying all the points where each type of bug can be injected, then injecting the bug. Many of these bugs injected are vulnerabilities that can be used to test and compare the performance of the scanners.

The use of model checkers for security analysis was also proposed [28]. In this case, the vulnerability is injected by mutating the formal model of the web application. The model is also

used to generate test cases that are used to attack the web application in a semi-automatic way.

The list of possible types of vulnerabilities affecting web applications is enormous, but XSS and SQLi are at the top of that list, accounting for 32 percent of the vulnerabilities observed [3], [6]. This is why we focus on those two important vulnerabilities, SQLi and XSS.

Attack Scenario Remarks

An attack can be considered successful if it leads to an “error” [14]. Obviously, the consequences of the attack (the “failure” and its severity) are dependent on the concrete situation, on what is compromised (credit card numbers, social security numbers, bank account information, passwords, emails, etc.), on how it is compromised (information disclosure, ability to alter the data or to insert new data, etc.) and on how valuable is the compromised asset (the value to the company, to the client from which the information belongs, to the companies operating in the same market, etc.) [10]. Although it is not a direct goal of the attack injection methodology presented here it can, however, provide important insights about security related issues allowing further analysis to obtain data about the consequences of the attack.

To avoid attacks, web application developers are currently reducing the number of error messages displayed to the user. This does not prevent SQLi attacks, but makes it harder to identify SQLi vulnerabilities using the black-box approach. However, after the vulnerability is found it is as easy to exploit as it was before. One consequence of this trend is an extraordinary increase in the false-positive and false-negative rates of black-box testing tools such as automatic web application vulnerability scanners [29], [27]. This also applies to other security mechanisms that use the same methodology, like the SQLmap sponsored by the OWASP project, for example [30]. The attack injection approach described in this chapter is quite immune to this countermeasure technique, because of the way the data used for the analysis is obtained: through the use of probes placed in different layers of the web application setup and correlating their data (e.g., HTTP and SQL interactions).

SQL Injection Techniques

Tautologies One method to gain unauthorized access to data is to insert a tautology into the query. In SQL, if the where clause of a SELECT or UPDATE statement is disjuncted with a tautology, then every row in the database table is included in the result set.

To illustrate, consider an online message board application. Assume that a user has logged into the web site properly. To update their account information, the user navigates to the proper page. In the query string, the member id is maintained. The web page submits, in the query string, details.asp?id=22. In middleware, the query SELECT * FROM members WHERE memberid=22 is generated, and the appropriate information is returned back to the user. However, an attacker could easily manipulate this interaction by editing the query string to contain a tautology, such as details.asp?id=22 OR 1=1. The resulting query is then SELECT * FROM members WHERE memberid=22 OR 1=1, which will select the top user in the users table (user id 1 may not be a valid id). Often, this is an admin, because they are the first to use the application.

The attacker is now free to read and modify the admin’s credentials. Checking for tautologies can be difficult, because SQL allows a wide range of function calls and values. Simply checking user input for patterns such as n=n or even for an equals sign is not sufficient. For example, other SQL tautologiesare ’greg’ LIKE ’%gr%’ and ’greg’=N’greg’ which are based on operators, such as LIKE and =N that are not typical math operators.

UNION Queries Another SQL injection technique involves the UNION keyword. SQL allows two queries to be joined and returned as one result set. For example, SELECT col1, col2, col3 FROM table1 UNION SELECT col4,col5,col6 FROM table2 will return one result set consisting of the results of both queries1 .

Let us return to our previous example, SELECT * FROM members WHERE memberid=22. If the attacker knew the number and types of the columns in the first query, an additional query such as SELECT body,results FROM reports can be appended. For some applications, surmising this information is not difficult. If the programmer is not consuming all exceptions, incorrect SQL queries will generate error messages that expose the needed information [12]. For example, if the two queries in the UNION clause have a disparate number of columns, an error such as All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists will be returned.

The attacker merely changes the query to SELECT * FROM reports WHERE reportid=22 UNION SELECT username,password,1 FROM members to try additional queries. The attacker would then continue to add dummy columns until an error such as Syntax error converting the varchar value ’feet’

to a column of data type int occurs. This signals that the column count is correct, but at least one column type is not. The attacker then alters the types accordingly.Additional Statements An interesting point when using a UNION to select multiple requests is that often only the first row of the result set is used by the web page. In this scenario, the attacker does not necessarily benefit from returning more rows than what was intended. However, a similar but alternative approach is to UNION the first query with a new query that does not return addition results. These new queries often perform specific actions on the database which can have disastrous consequences. For example, Microsoft’s SQL Server provides two system level stored procedures designed to aid administrators.

These tools inadvertently provide powerful features to an attacker. The first is the xp cmdshell(string) command. This function can be UNION ’d with any other query. The effect is essentially that the command passed to the function will be executed on the server as a shell command. Another interesting system procedure is sp execwebtask (sql,location). This command executes the SQL query and saves the results as a web page at the specified location. The location need not be on the database server, it can be placed in any accessible UNC path. For example, SELECT * FROM reports WHERE reportid=22 UNION sp make webtask ’\\IP address\ share\test.html’,’SELECT * FROM users’ will create an HTML page of the entire users table onto the server IP address.

Using Comments SQL supports comments in queries. Most SQL implementations, such as T-SQL and PL/SQL use ’- -’ to indicate the start of a comment (although occasionally ’#’ is used). By injecting comment symbols, attackers can truncate SQL queries with little effort. For example, SELECT * FROM users WHERE username=’greg’ AND password=’secret’ can be altered to SELECT

* FROM users WHERE username=’admin’ - - AND password=”. By merely supplying admin’ - - as the username, the query is truncated, eliminating the password clause of the WHERE condition. Also, because the attacker can truncate the query, the tautology attacks presented earlier can be used without the supplied value being the last part of the query, or an int. Thus attackers can create queries such as SELECT * FROM users WHERE username=’anything’ OR 1=1 - - and password=’irrelevant’. This is guaranteed to log the attacker in as the first record in the users table, often an administrator.Failure detection strategies can be implemented as local or remote detection modules, depending on whether they are or not deployed on the same node

of the monitored component. Local and remote detection can be both implemented with query-based or log-based techniques. Query-based techniques rely on interrogating the monitored component health status, to discover potential anomalies. The query can be performed periodically (heartbeat techniques, such as [8, 9]), or implicitly each time another distributed component tries to invoke the component of interest [10]. On the other hand, log-based techniques consist in analyzing the log files produced by the component, if available [11, 12].

In fact, these may contain many useful data to comprehend the system dependability behavior, as shown by many studies on the field [13, 14]. Moreover, logs are the only direct source of information available in the case of OTS items.

Both query-based and log-based techniques can be considered as direct detection techniques: hey try to infer the component health status by directly querying it or by analyzing data items directly logged by the component itself. A different approach would instead be to infer the health of the observed component by monitoring its behavior from an external viewpoint, along with its interactions with the environment. These approaches can be labeled as indirect failure detection techniques. As an example, the work in [7] exploits hardware performance counters and OS signals to monitor the system behavior and to signal possible anomalous conditions. For instance, as better detailed an active hang is flagged if the instruction count executed by the process goes outside a given bound. However, this technique is not useful in the case of passive hangs, where instructions are not executed.

Indirect techniques have been especially adopted for intrusion detection systems. In these cases, anomaly detection approaches are used to compare normal and anomalous runs of the system. In [15] the execution of a program is characterized by tracing patterns of invoked system calls. System call traces produced in the operational phase are then compared with nominal traces to reveal intrusion conditions. Other solutions, such as [16, 17], are based on data mining approaches, such as document classification. They extract recurrent execution patterns (using system calls or network connections) to model the application under nominal conditions, and to classify run-time behaviors as normal or anomalous. Notwithstanding the high degree of accuracy that these solutions are able to achieve, they require high computational load (due to the huge volume of analyzed data), which is inadequate to perform on-line detection in critical systems. Moreover, they have been applied to intrusions, which are

deliberate software faults, rather than on transient software faults. Hence, it is not clear whether they are able to detect software hang failures due to transient faults.3.1 Pseudo Code for hacking Select SQL statements

Open a connection to SQL

Prepare an SQL Command for select statement. E.g. string sQuery = “Select 1 from Table Name where UserName=’”+txtUname.text+”’ and Password=’”+txtPass.text+”’;”

Boolean bFlag = ExecuteSQL(Squery);

If a hacker tries to inject a known username e.g ‘MyUserName” followed by single apostrophe and double hyphen i.e. My Username’—then MSSQL will comment the statement there after and always return the value as true, thus letting the hacker into the application system.

3.1.2. SQLI Attack Method 2

If the application system takes in an user input and executes the query and binds the data to an data grid dynamically based on the number of resultset returned, then the hacker can use a “;” a semicolon followed by the select statement ie “;select * from sysobject

where xtype=’u’;” to pull the list of tables used in a particular database.

3.2. Pseudo code for hacking insert statements

Open a connection to SQL

Frame an insert statement dynamically based on the inputs given e.g. string sQuery = “Insert into tablename (col1, col2)

Values = (’”+txtName.text+”’,’”+txtAddress.text+”’,’);”

ExecuteQuery (sQuery)

3.2.1. SQLI Attack Method 1

Here if an hacker tries to inject an input “Address1; Delete from table name ;’, then if appropriate permission are available for that system then it can completely wipe out the data e.g customer data for that organization.

Similarly we can use; Truncate table”, “; Drop table;’ instead of delete statement.

4. Existing Framework

In the existing process, User tries to give inputs that are passed to the DB server without validating for SQLIA. The hacker will try to inject the vulnerables trying to exploit the server.

Figure 1: Existing process for SQLIA by Hacker

The hacker tries to inject the vulnurables into the Web GUI and try to exploit the vulnerables.

5. Proposed Framework

In the below Fig .2 IBC replaces the regular Input control, that blocks the hacker from Injecting the vulnerables into the server. Thus acts as an internal firewall within an application.

Figure 2: Proposed Process for SQLIA Prevention

6. Proposed Solution

A simple solution thought of SQLIA attack is creating an custom component termed as Injection Box Control (IBC) with the below checks made at the code level to block the SQLIA.

Strip all the possible SQL vulnerables at the server side code e.g Truncate, Drop, Delete, etc. And pass the diffused vulnerable SQL to the Database server .ie. IBC act as an validation layer for the SQL vulnerables.

Set the attribute autocomplete="off" for the IBC.

Mark the cookie as HTTPOnly

Apply the following changes to your web.config file to prevent information leakage by using custom error pages and removing X-AspNet-Version from HTTP responses.

<System.Web>

< httpRuntime enableVersionHeader="false" />

<customErrors mode="On" defaultRedirect="~/error/GeneralError.aspx">

<error statusCode="403" redirect="~/error/Forbidden.aspx" />

<error statusCode="404" redirect="~/error/PageNotFound.aspx" />

<error statusCode="500" redirect="~/error/InternalError.aspx" />

</customErrors> </System.Web>

Set the ViewState Encryption mode to Always in config file. E.g.

<System.Web>

<pages viewStateEncryptionMode="Always">

</System.Web>

To avoid this, output should be encoded according to the output location and context. For example, if the output goes in to a JavaScript block within the HTML document, then output needs to be encoded accordingly.

7. Field Study Analysis on Vulnerability using SQLIA Tool – NetSparker

Analysed some of the live Web URL’s that take user input and process data

Table 1: Metrics on Vulnerable Categories Surveyed Over Above Url’s Using Netsparker

7.1. Critical Category Vulnerables

The Critical category vulnerables identified are

Password Transmitted over HTTP. The possible remedy is all the sensitive data need to be transferred via HTTPS instead of HTTP.

Permanent Cross-site scripting that allows an attacker to execute a dynamic script (infected JavaScript, VBScript) in the context of the application. The remedy is output need to be encoded using Microsoft Anti-cross-site scripting.

Cookie Not Marked as Secure. The possible remedy is mark all cookies used within the application as secure.

7.2. Medium Cater gory Vulnerable

Medium Cater gory vulnerable identified above are

Open Redirection

Source Code disclosure

Http Header Injection

7.3. Information Category Vulnerables

Information category vulnerables identified are

Forbidden Resource.

ASP.Net Framework Identified

Version Disclosure

HTTP Strict Transport Security Policy (HSTS) not enabled.

Robots.txt detected (i.e. hidden files are detected).

ASP.NET Debugging Enabled.

7.4. Low Category Vulnerables

Low Category vulnerable identified above are

Cookie not marked as Http Only.

Auto Complete enabled.

View State is not encrypted.

Internal IP Address disclosure

Internal Server Error detected

Cross Site Request Forgery Detected

Insecure Frame

Future Work

As part of future work, we plan to extend our prototype to develop a complete implementation of the proposed architecture. This would then be used as a test bed to evaluate the different web application scripts available in the public domain. We are currently exploring the security implications of incorporating well known randomization algorithms into our model in case the session id which is used to separate the user inputs from the SQL statement might be guessed by the attacker. We are also exploring the possibility of implementing this functionality as a middleware to the database engine, to avoid explicit instrumentation of source code.

Conclusion

Web application developers need more extensive training to raise their awareness about SQL injection and to become familiar with state-of-the-art defenses. At the same time, they need sufficient time and resources to implement security measures. Too often, project managers pay less attention to security than to functional requirements. Second, researchers should implement their proposed approaches and make such implementations, along with comprehensive user manuals, available either commercially or as open source. Too many existing

techniques are either not publicly available or are difficult to adopt. Readily available tools would motivate more developers to combat SQL injection.

References:

[1] C. Anley, “Advanced SQL Injection in SQL Server Applications,” white paper, Next Generation Security Software Ltd., 2002;

[2] W.G.J. Halfond, J. Viegas and A. Orso, “A Classification of SQL Injection Attacks and Countermeasures.”, Proc. Int’l Symp. Secure Software Eng. (ISSSE 06), IEEE CS, 2006;

[3] D. Saravanan and Dr. S. Srinivasan, “Matrix Based Indexing Technique for Video Data.”, International journal of Computer Science”, 9 (5): 534-542, 2013,pp 534-542.

[4] R.A. McClure and I.H. Krüger, “SQL DOM: Compile Time Checking of Dynamic SQL Statements,” Proc. 27th Int’l Conf. Software Eng. (ICSE 05), ACM, 2005, pp. 88-96.

[5] S. Thomas, L. Williams, and T. Xie, “On Automated Prepared Statement Generation to Remove SQL Injection Vulnerabilities,” Information and Software Technology, Mar. 2009, pp. 589-598.

[6] Y. Shin, L. Williams, and T. Xie, “SQLUnitGen: Test Case Generation for SQL Injection Detection.”, tech. report TR 2006-21, Computer Science Dept., North Carolina State Univ., 2006.

[7] H. Shahriar and M. Zulkernine, “MUSIC: Mutation-Based SQL Injection Vulnerability Checking,” Proc. 8th Int’lConf. Quality Software (QSIC 08), IEEE CS, 2008, pp. 77-86.

[8] D. Saravanan and Dr. S. Srinivasan, “ A proposed New Algorithm for Hierarchical Clustering suitable for Video Data mining.”, International journal of Data Mining and Knowledge Engineering”, Volume 3, Number 9, July 2011.Pages 569-572.

[9]. J. Fonseca, M. Vieira, and H. Madeira, “Vulnerability &Attack Injection for Web Applications,” Proc. 39th Ann. IEEE/IFIP Int’l Conf. Dependable Systems and Networks (DSN 09), IEEE, 2009, pp. 93-102.

[10] X. Fu and C. C. Li, “A String Constraint Solver for Detecting Web Application Vulnerability.”, Proc. 22nd Int’l Conf. Software Eng. and Knowledge Eng. (SEKE 10), Knowledge Systems Institute Graduate School, 2010, pp. 535-542.

[11] A. Kiezun et al., “Automatic Creation of SQL Injection and Cross-Site Scripting Attacks,” Proc. 31st Int’l Conf. Software Eng. (ICSE 09), IEEE CS, 2009, pp. 199-209.

[12] D. Saravanan and Dr. S. Srinivasan, “Data Mining Framework for Video Data”, In the Proc. of International Conference on Recent Advances in Space Technology Services & Climate Change (RSTS&CC-2010), held at Sathyabama University, Chennai, November 13-15, 2010.Pages 196-198.

[13] N. Alshahwan and M. Harman, “Automated Web Application Testing Using Search Based Software Engineering,” Proc. 26th IEEE/ACM Int’l Conference Automated Software Eng. (ASE 11), IEEE, 2011, pp. 3-12.

[14] K.J. Biba, “Integrity Considerations for Secure Computing Systems.”, tech. report ESD-TR-76-372, Electronic Systems Division, US Air Force, 1977.

[15] V.B. Livshits and M.S. Lam, “Finding Security Vulnerabilities in Java Programs with Static Analysis,” Proc. 14th Conf. Usenix Security Symp. (Usenix-SS 05), Usenix, 2005;

[16] Y. Xie and A. Aiken, “Static Detection of Security Vulnerabilities in Scripting Languages.”, Proc. 15th Conf Usenix Security Symp. (Usenix-SS 06), Usenix, 2006;

[17] G. Wassermann and Z. Su, “Sound and recise Analysis of Web Applications for Injection Vulnerabilities.”, Proc. ACM SIGPLAN Conf. Programming Language Design and Implementation (PLDI 07), ACM, 2007, pp. 32-41.

[18] L.K. Shar and H.B.K. Tan, “Mining Input Sanitization Patterns for Predicting SQL Injection and Cross Site Scripting Vulnerabilities,” Proc. 34th Int’l Conf. Software Eng. (ICSE 12), IEEE, 2012, pp. 1293-1296.

[19] D. Saravanan and Dr. S. Srinivasan, “Video Image Retrieval Using Data Mining Techniques “Journal of Computer Applications, Volume V, Issue No.1. Jan-Mar 2012. Page 39-42. ISSN: 0974-1925.

[20] S.W. Boyd and A.D. Keromytis, “SQL rand: Preventing SQL Injection Attacks,” Proc. 2nd Conf. Applied Cryptography and Network Security (ACNS 04), LNCS 3089, Springer, 2004, pp. 292-302.

[21] D.T. Stott, B. Floering, D. Burke, Z. Kalbarczpk, and R.K. Iyer, “NFTAPE: A Framework for Assessing Dependability in Distributed Systems with Lightweight Fault

Injectors,” Proc. Computer Performance and Dependability Symp., 2000.

[22] J. Christmansson and R. Chillarege, “Generation of an Error Set that Emulates Software Faults,” Proc. IEEE Fault Tolerant Computing Symp., 1996.

[23] H Madeira, M. Vieira, and D. Costa, “On the Emulation of Software Faults by Software Fault Injection,” Proc. IEEE/IFIP Int‘l Conf. Dependable System and Networks, 2000.

[24] J. Dur~aes and H. Madeira, “Emulation of Software Faults: A Field Data Study and a Practical Approach,” IEEE Trans. Software Eng. vol. 32, no. 11, pp. 849-867, Nov. 2006.

[25] N. Neves, J. Antunes, M. Correia, P. Ver_ıssimo, and R. Neves, “Using Attack Injection to Discover New Vulnerabilities,” Proc. IEEE/IFIP Int’l Conf. Dependable Systems and Networks, 2006.

[26] J. Fonseca, M. Vieira, and H. Madeira, “Testing and Comparing Web Vulnerability Scanning Tools for SQLi and XSS Attacks,” Proc. IEEE Pacific Rim Int’l Sump Dependable Computing, Dec. 2007.

[27] Ananta Security “Web Vulnerability Scanners Comparison,” anantasec.blogspot.com/2009/01/web-vulnerability-scannerscomparison. html, accessed 1 May 2013, 2009.

[28]. M. Buchler, J. Oudinet, and A. Pretschner, “Semi-Automatic Security Testing of Web Applications from a Secure Model,” Proc. Int’l Conf. Software Security and Reliability, 2012

[29]. J. Grossman, “SQLi, Eye of the Storm,” The Security J., vol. 26, pp. 7-10, 2009.

[30] B. Damele, “Sqlmap: Automatic SQLi Tool,” sqlmap. Source forges Net, Accessed 1 May 2013, 2009.

- Zahra Shafiei is a Student at the University of JNTUH and Completed bachelor in mathematics applied in computer. She is an expert on security in cloud environment and her research interests also include experimental Security evaluation, fault injection, security benchmarking, software development processes, and software quality assurance.