Securing Web Application Using Brocken Authentication & Session Management, Cross Site Request Forgery & Scripting Attacks and SQL Injection

ovenforksqueeSecurity

Nov 3, 2013 (3 years and 11 months ago)

107 views

Available ONLINE
www.vsrdjournals.com





VSRD
-
IJCSIT, Vol. 2 (4
), 201
2
,
1
-
5



____________________________

1
Research Scholar
, Department of
Computer Application
,
Manav Bharti University
,
Solan
,
Himanchal
Pradesh,
INDIA.


2
Assistant Professor, Department of Computer Science, RKNEC, Nagpur, Maharashtra, INDIA.

3
Assistant Professor, Department of Computer Science, Jaypee University of Information Technology, Solan, Himanchal
Pradesh, INDIA.
*Correspondence :
dcmishra9
9@gmail.com

R
R
R
E
E
E
S
S
S
E
E
E
A
A
A
R
R
R
C
C
C
H
H
H



C
C
C
O
O
O
M
M
M
M
M
M
U
U
U
N
N
N
I
I
I
C
C
C
A
A
A
T
T
T
I
I
I
O
O
O
N
N
N



Securing Web Application

Using Brocken Authentication
&
Session
Management,
Cross Site Request Forgery

&
Scripting Attacks and
SQL Injection

1
Dinesh Chandra
Mishra
*
,

2
Pankaj Agrawal

and
3
Amit Kr. Srivastava

ABSTRACT

Have it ever think that the web applications are safe? What is the use of doing money transfer transaction,
shopping, etc if it is unsafe. The Role of web application security is very important for

such an activity. The web
applications must be safe as you can believe. With the growing online web applications, web application
security plays a great role. It helps to ensure the trust of the user, helps in outsourcing, helps to reduce the risks,
helps

to reduce maintenance cost, helps to control the economy as Internet banking is the backbone of any
developed or developing country. In this paper we are introducing Brocken Authentication & Session
Management, Cross Site Request Forgery & Scripting Attac
ks and SQL Injection attacks Some of the questions
arises when we talk about the security of web application. Is the application having secure login?. Is the firewall
smart enough to handling the threats?. Is web application is having
Secure Sockets Layer?
. Is there any scope of
easy hacking (like directory browsing, empty password etc)?.
And the answer is only one: Web Application
Security

Keywords :

Web Application Security, Brocken Authentication & Session Management,
Cross Site Request
Forgery,
CrossSite Scripting Attacks,
SQL Injection.

1.

INTRODUCTION

Indeed according to surveys, security issues in web applications are the most commonly reported vulnerabilities
on the Internet. Below is the description of the most common threats in the web applic
ation security[22].
Awareness and education on these issues must be increased. Good habits must be taught from the beginning.
Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
2

of 9


People need to be taught correctly from the beginning how to design, develop and implement in a secure
manner. For developing the
secure web application one must consider the each step with great care. To run the
web application more durably and more secure, the above mentioned designing steps are very important. From
client side to server side scripting and from web application to b
ack
-
end (database), Web application Developer
is expected to follow the steps. In this paper we have mentioned how to handle with the common threats using
different parameters. Secure web application is the solution to handle the threats
.

2.

BROCKEN AUTHENTIC
ATION AND SESSION MANAGEMENT

Broken Authentication session management evolves

Automated process of trial and error
,
Guess a person
username and password, credit
-
card number, cryptographic key,

System sends a value and waits for the
response, then tries an
other value, and so on.

Many systems allow the use of weak passwords.

An attacker will
cycle through a dictionary (word by word),

Generates thousands (potentially millions) of incorrect guesses.
When the guessed password is OK, attacker can access the acc
ount[5].

Same techniques can be used to guess
encryption keys, When the size of the key is small or an attacker will test all possible keys.

Attacker has the
possibility to listen to the traffic of the Victim as

Listens to the traffic at the IP level (sn
iffer). Client connects to
the HTTP server.

Visits a page containing a login form (url is HTTPS). Receives a cookie containing his
session ID.

Sends his credentials encrypted (HTTPS). Attacker receives following information



Session ID



Sees that the user h
as sent his credentials (using an encrypted connection to the server)



Attacker can use the cookie to be recognized as the legitimate user

Using Autonomy’s pattern
-
matching technology allows the Brio Knowledge Server component to search for
“content in any
language and format, from any location, and present it automatically with hyperlinks to similar
information” through an active client service component WebClient. The WebClient component controls what
users see and access through the portal. A Name Server
component is used to manage service
-
agent
configuration information, authentication, and initialization service as well as provide directory lookup. Session
management is provided through a Service Broker that acts as a service
-
agent gateway server and dyn
amic load
balancer to handle user requests. An Authentication Service component provides WebClient with client
-
service
authentication through an internal authentication driver or an external authentication service.

The Repository manages object storage, s
earch, browsing, or retrieval actions on the object repository. The Job
Factory “requests services from external DBMS or Enterprise Resource Planning (ERP) systems and delivers
the job output both to the end
-
user, through the WebClient, and to the Reposito
ry, for future distribution.” An
Event Server schedules Job Factory agents as well as provides users with a subscribable notification service. A
centralized Administrator manages objects, categories, users, schedules, and services. An Integrator uses a Jav
a
Application Program Interface to integrate other systems with the Brio Portal. Security is achieved through
profile
-
driven content and object
-
level access that “integrates with other user
-
authentication mechanisms
including NT domains, LDAP, NIS/NIS+ and

third party single sign
-
on security.” Finally, the use of the
Wireless Markup Language (WML) supports two
-
way interaction for wireless devices through wireless Internet
Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
3

of 9


service providers[18].

Authentication and session management includes all aspects of h
andling user authentication and managing
active sessions. Authentication is a critical aspect of this process, but even solid authentication mechanisms can
be undermined by flawed credential management functions, including password change, forgot my passwo
rd,
remember my password, account update, and other related functions should require re
-
authentication even if the
user has a valid session id[6]. The Session Management Protocol (SMP) is an important part of a session layer
for mobile, disconnection
-

and

delay
-
tolerant communication developed at Ericsson Research. This layer lets
applications use sessions instead of sockets to communicate with network endpoints. Such sessions are very
persistent, surviving even network outages and changes in network attac
hment. SMP may run on top of TCP/IP
or other network protocols, and handles data integrity and resumption after disconnection and suspension for
sessions. It also deals with sending and processing messages related to the communication context.

3.

CROSS SITE
REQUEST FORGERY

CSRF is a very simple attack. We have been discussing here hijacking and other types of attacks that are more
complex to mount and CSRF is very simple. CSRF is where you have a link to a sensitive application, some
transaction in that appli
cation and embedded within an attacker's controlled page. It works mostly because of
careless users and because of tab browsers[19]. You go to your browser, you open your banking application,
your online banking application. You log in. You do whatever you

do and then you leave this tab open with the
application and then open another tab on the same browser. And go wherever you feel like, and use sites,
portals and so on. Quite a few of them are not as secure as we would like them to be, obviously. Then i
f you get
to a page that has been compromised or is controlled by a malicious individual to begin with, and that page
contains a link that instructs the banking application to do something like fund transfer or some kind of financial
transaction, then that

request would go to the banking application with the session identifier that you have
already created by logging into the application [21].

The transaction will be automatically executed without you noticing it. That’s as simple as cross site request
for
gery is embedding a link within a page owned by the attacker. The link would be an image item within that
page. It could be a scrape reference within the page. It could be everything that accepts a URL reference within
an HTML page. Cross
-
Site Request Forg
eries, or short CSRF, is another threat against web applications. It takes
advantage of applications that trust their users. The attacker uses this trust for his/her purposes. An attack can be
against e.g: A user in a forum. The attacker can post the text

he wants with the help of the rightful users account
but without the user’s knowledge. The new post will be signed by the valid user. A customer in a web shop. The
attacker orders merchandise for the customer, by the customer without the customer’s knowle
dge of what
happened.

An attack can be against e.g: A user in a forum. The attacker can post the text he wants with the help of the
rightful users account but without the user’s knowledge. The new post will be signed by the valid user. A
customer in a web
shop. The attacker orders merchandise for the customer, by the customer without the
customer’s knowledge of what happened. The attacker uses info that is sent by a HTTP request, which is a
protocol sent from the web browser of the client to the server Usua
lly the image tag in HTML is used for CSRF
Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
4

of 9


attacks, where the attacker puts an URL that runs a command instead of putting a URL to an image. This can be
exploited because the server does not know that it was an image that was requested, the request handles

all the
URLs in the same way (http://shiflett.org/articles/foiling
-
cross
-
site
-
attacks, 2005
-
04
-
08).


An attack can be against e.g: A user in a forum. The attacker can post the text he wants with the help of the
rightful users account but without the user’
s knowledge. The new post will be signed by the valid user. A
customer in a web shop. The attacker orders merchandise for the customer, by the customer without the
customer’s knowledge of what happened.

4.

SQL INJECTIONS

SQL Injection Attacks are a relatively

recent threat to the confidentiality, integrity and availability of online
applications and their technical infrastructure, accounting for nearly a fourth of web vulnerabilities [1]. In this
paper, and numerous references therein, we present our study on
the prevention of SQL Injections: overview of
proposed approaches and existing solutions, and recommendations on preventive coding techniques for Java
-
powered web applications and other environments[2]. Then, we review McClure’s SQL DOM [23] approach for
t
he prevention of SQL Injections in object
-
oriented applications. We also present our solution for Java
-
based
online applications, SQLDOM4J, which is freely based on the SQL DOM but attempts to address some of our
criticisms toward it, and evaluate its perf
ormance.

Communications between applications and databases is often performed using a language known as Structured
Query Language, or SQL. SQL is a language standard implemented by numerous database systems, including
MySQL, PostgreSQL, and SQLite. SQL str
uctures database queries in a way that it similar to the English
language. For example, to query a database for all users, one might use a query like SELECT user FROM users.
The simplicity of SQL’s syntax, combined with the complexity and power of its oper
ation, allow for a set of
database exploits known as SQL injections, an exploit in which an attacker takes advantage of SQL’s syntax to
perform malicious operation without the express consent of the application. For example, pretend that a
developer has a
database of user
-
password pairs. This data is stored in the table users, and consists of two
columns: user, which contains the username; and password, which contains a hash of the user’s password.
Assume again that this database backs a web application, wh
ich allows a user to log in via an HTML form that
contains the fields loginUser and loginPassword. The web application might construct a SQL query using the
string.

SELECT COUNT(*) FROM users WHERE user = ‘ + loginUser + ’ AND

password = ‘ + loginPassword
+ ’;

This query would return the number of users with the specified user
-
password pair. If, for example, the user
entered the username me and the password password, the web application would construct the SQL query.

SELECT COUNT(*) FROM users WHERE user =
‘me’ AND

password = ‘password’;

SQL statements are terminated with a semicolon. This allows more than one statement to be sent to the database
at a time. This property of SQL’s syntax can easily be exploited by malicious users. For example, assume now
that

the user enters the username me and the password a’;

Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
5

of 9


DROP TABLE users; SELECT * FROM users WHERE user LIKE ‘ .

Certainly this is a weird password, but it is constructed for a very sinister purpose: to delete the users table.

SELECT COUNT(*) FROM users WH
ERE user = ‘me’ AND password = ‘a’;

DROP TABLE users;

SELECT * FROM users WHERE user LIKE ‘’;

A SQL query after a successful SQL injection.

SQL Injection Attacks (SQLIA’s) [3, 4] are carried out by submitting maliciously crafted inputs to database
-
driven
applications, such as interactive web sites. These inputs are then used by applications to build dynamic
SQL queries, and have the potential to alter the semantic structure of the query, due to the lack of separation of
control and data in SQL. The numerou
s SQLIA techniques used by attackers are based on the many statement
structure combinations offered by SQL, and sometimes also take advantage of additional features in specific
DBMS implementations, particularly Microsoft’s SQL Server. They pursue differen
t goals at various levels,
from allowing other techniques to be used (SQLIA escalation) to actually extracting database data. The resulting
threats are various and range from system fingerprinting to Denial
-
of
-
Service (DoS) and theft of confidential
inform
ation. SQL Injections Attacks thus threaten the confidentiality, integrity and availability of databases’
data and structure, of their hosting systems and of their dependant applications, and as such greatly require the
attention of application developers
and the deployment of effective prevention solutions. Protection products
which can be used to prevent SQL Injections in online applications have been emerging these last 3 years, in the
form of Web Application Firewalls (WAFs), HIPS solutions and more lat
ely Database Extrusion Protection
(DBEP) systems [5].

Snort
-
based solutions
are used by many organizations who wish to leverage their IDS experience. They will
catch some SQLIA’s as Snort packages some database vulnerabilities, but it only features signatu
re
-
based
detection and thus can’t offer serious protection [6].
Host
-
based IDS
, such as Application Security’s DbProtect
[7], while not targeted at prevention, are mentioned as they play an important role: they provide advanced
auditing, enabling organizat
ions to comply with regulatory requirements. They can notably detect insider attacks


70% of all database attacks [8].
WAFs
[9] use SPI and Deep
-
Packet Inspection methods to inspect the data
portion of HTTP traffic, blocking protocol violations and malic
ious content (cookies, POST, GET) and ship
with enterprise
-
class features such as load balancing and HTTP acceleration. The most renowned and rewarded
commercial WAF products are Imperva’s SecureSphere Web Application Firewall [10] and F5 Networks’ Big
-
IP
Application Security Module [11]. These products are gaining a well
-
established position in the web and
application security market, which is also influenced by expert organizations such as the OWASP Foundation
and the WASC. They are quite effective as the
y use a combination of signatures, behaviour analysis and user
policies. ModSecurity [12] is a famous open source WAF for Apache with over 10,000 commercial
deployments worldwide. According to a Forrester Research study published in 2006 [13], it provides
the “best
attack detection for web application threats”. It runs as an Apache module either in reverse proxy or in
embedded mode provides many features. Its strength notably relies in its high customization capability which
enables users to for instance sp
ecify script
-
specific parameter filters. eEye

Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
6

of 9


Digital Security’s SecureIIS [14] could perhaps be considered the commercial MSoriented counterpart to
ModSecurity. It runs as an ISAPI filter in order to integrate closely with the IIS, which allows it to insp
ect SSL
traffic once it’s decrypted. Its detection strategy relies both on behaviour analysis and on a base of known
vulnerabilities. Its advantage apparently resides in its behaviour analysis
-
like CHAM (Common Hacking Attack
Methods) technology which iden
tifies generic attack methods and enables it to prevent unknown (zero
-
day)
attacks [15]. It is said to have blocked all the new attacks conducted against IIS since its first deployment [14].
Nonetheless, it lacks important features such as auditing which i
s critical for organizations concerned with
compliance issues.


SQL Injection Attack On Different Parameters Of User Input

5.

CROSS SITE SCRIPTING ATTACKS

Web applications are becoming the dominant way to provide access to on
-
line services. At the same time,

web
application vulnerabilities are being discovered and disclosed at an alarming rate. Web applications often make
use of JavaScript code that is embedded into web pages to support dynamic client
-
side behavior[10]. This script
code is executed in the con
text of the user’s web browser. To protect the user’s environment from malicious
JavaScript code, a sand
-
boxing mechanism is used that limits a program to access only resources associated with
its origin site. Unfortunately, these security mechanisms fail
if a user can be lured into downloading malicious
JavaScript code from an intermediate, trusted site. In this case, the malicious script is granted full access to all
resources (e.g., authentication tokens and cookies) that belong to the trusted site. Such

attacks are called cross
-
site scripting (XSS) attacks. In general, XSS attacks are easy to execute, but difficult to detect and prevent. One
reason is the high flexibility of HTML encoding schemes, offering the attacker many possibilities for
circumventin
g server
-
side input filters that should prevent malicious scripts from being injected into trusted
sites. Also, devising a client
-
side solution is not easy because of the difficulty of identifying JavaScript code as
being malicious. Here we presents Noxes,

which is, to the best of our knowledge, the first client
-
side solution to
mitigate cross
-
site scripting attacks. Noxes acts as a web proxy and uses both manual and automatically
generated rules to mitigate possible cross
-
site scripting attempts. Noxes eff
ectively protects against information
leakage from the user’s environment while requiring minimal user interaction and customization effort. The
problem with the current JavaScript security mechanisms is that scripts may be confined by the sand
-
boxing
mech
anisms and conform to the same
-
origin policy, but still violate the security of a system. This can be
achieved when a user is lured into downloading malicious JavaScript code (previously created by an attacker)
from a trusted web site. Such an exploitation

technique is called a cross
-
site scripting (XSS) attack [16, 17].

Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
7

of 9


Cross
-
Site Scripting attacks (XSS attacks for short) are those attacks against web applications in which an
attacker gets control of a user’s browser in order to execute a malicious script
(usually an HTML/JavaScript
code) within the context of trust of the web application’s site. As a result, and if the embedded code is
successfully executed, the attacker might then be able to access, passively or actively, to any sensitive browser
resource

associated to the web application (e.g., cookies, session IDs, etc.).

Although web applications development has efficiently evolved since the first cases of XSS attacks were
reported, such attacks are still being exploited day after day. Since late 90’s, attackers have managed to continue
exploiting XSS attacks across Intern
et web applications although they were protected by traditional network
security techniques, like firewalls and cryptography
-
based mechanisms. The use of specific secure development
techniques can help to mitigate the problem. However, they are not always
enough. For instance, the use of
secure coding practices (e.g., those proposed in [18]) and/or secure programming models (e.g., the model
proposed in [19] to detect anomalous executing situations) are often limited to traditional applications, and
might no
t be useful when addressing the web paradigm. Furthermore, general mechanisms for input validation
are often focused on numeric information or bounding checkins (e.g., proposals presented in [10, 21]), while the
prevention of XSS attacks should also addres
s validation of input strings.

XSS vulnerabilities are being discovered and disclosed at an alarming rate. XSS attacks are generally simple,
but difficult to prevent because of the high flexibility that HTML encoding schemes provide to the attacker for
cir
cumventing server
-
side input filters. Script
-
based XSS attack and predicts that semi
-
automated techniques
will eventually begin to emerge for targeting and hijacking web applications using XSS, thus eliminating the
need for active human exploitation. Sever
al approaches have been proposed to mitigate XSS attacks. These
solutions, however, are all server
-
side and aim to either locate and fix the XSS problem in a web application, or
protect a specific web application against XSS attacks by acting as an applica
tion
-
level firewall. The main
disadvantage of these solutions is that they rely on service providers to be aware of the XSS problem and to take
the appropriate actions to mitigate the threat. Unfortunately, there are many examples of cases where the servic
e
provider is either slow to react or is unable to fix an XSS vulnerability, leaving the users defenseless against
XSS attacks.

6.

CONCLUSION

In this paper important threats are described which intrudes the web application security. We Should keep
different t
ype of the threats and their solution in mind before developing the web application. For a web
application development what steps should be followed.
Web application security is the demand of the new era.
Now security is no more only for networks, it has
increased its wings now. If we talk about anything like
banking, paying bills, shopping, ticket booking etc, physically or virtually the web plays its role. Keeping every
aspect in mind web application security is as important as circulation of the blood f
or living system. As web is
helping us a lot in every step, there are a lot of problems and insecurity for the same, to handle this web
application security comes into the picture. Web application security ensures the task, whatever you are doing is
safe.
Web applications are increasingly the preferred targets of cyber
-
criminals looking to profit from identity
theft, fraud, corporate espionage, and other illegal activities. The impact of an attack can be significant, and
include costly and embarrassing serv
ice disruptions, down
-
time, lost productivity, stolen data, regulatory fines,
Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
8

of 9


angry users and irate customers. Beyond preserving the corporate brand, federal and state legislation and
industry regulations are now requiring web applications to be better pro
tected.

7.

REFERENCES

[1]

Andrews, M.: Guest Editor's Introduction: The State of Web Security. IEEE Security and

Privacy, 4, 4, 14
--
15 (2006)

[2]

Janot, E.: SQLDOM4J: Preventing SQL Injections in Object
-
Oriented Applications. Master

thesis,
Concordia University Colle
ge of Alberta (2008),
http://waziboo.com/thesis

[3]

OWASP Foundation: SQL Injection,
http://www.owasp.org/index.php/SQL_injection

[4]

Chapela, V.: Advanced SQL Injection,

http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt

[5]

Janot, E.: SQLDOM4J: Preventing S
QL Injections in Object
-
Oriented Applications. Master

thesis,
Concordia University College of Alberta (2008), http://waziboo.com/thesis

[6]

Kost, S., Kanter, J.: Evading Network
-
Based Oracle Database Intrusion Detection Systems,

http://www.integrigy.com/securi
tyresources/

whitepapers/Integrigy_Evading_Oracle_IDS.pdf

[7]

Application Security Inc. DbProtect,
http://www.appsecinc.com/products/dbprotect

[8]

Cole, L.: AppSecInc to Launch Database Security Suite. Database Journal (2007),

http://www.databasejournal.com/news/a
rticle.php/3657096

[9]

Ristic, I.: Web Application Firewalls: When Are They Useful?. OWASP AppSec Europe

2006,

http://owasp.org/images/9/9c/OWASPAppSecEU2006_WAFs_WhenAreTheyUseful.ppt

[10]

Imperva SecureSphere Web Application Firewall,
http://imperva.com/products/waf.html

[11]

F5 BIG
-
IP Application Security Manager,
http://www.f5.com/products/big
-
ip/productmodules/

application
-
security
-
manager.html

[12]

ModSecurity,
http://modsecurity.org

[13]

Gavin, M.: The Forrester Wave™: Web Application Firewalls,
Q2 2006,

http://www.forrester.com/Research/Document/Excerpt/0,7211,38766,00.html

[14]

SecureIIS Web Server Security,
http://eeye.com/html/assets/pdf/datasheet_secureiis.pdf

[15]

eEye Digital Security: Windows 2000 IIS 5.0 Remote Buffer Overflow Vulnerability(Remote
SYSTEM
Level Access),

http://research.eeye.com/html/advisories/published/AD20010501.html

[16]

David Endler. The Evolution of Cross Site Scripting

Attacks. Technical report, iDEFENSE Labs, 2002.

[17]

CERT. Advisory CA
-
2000
-
02: malicious HTML tags

embedded in client w
eb requests.

http://www.cert.org/advisories/CA
-
2000
-
02.ht ml
,

2000.

[18]

Howard, M. and LeBlanc, D.
Writing secure code
. Microsoft Press, Redmond, 2nd ed.,

2003.

[19]

Forrest, S., Hofmeyr, A., Somayaji, A., and Longstaff, T. A sense of self for unix processes.

IEEE
S
ymposium on Security and Privacy
, pp. 120

129, 1996.

[20]

Larson, E. and Austin, T. High coverage detection of input
-
related security faults.
12

USENIX Security
Simposium
, pp. 121

136, 2003.

[21]

Ashcraft, K. and Engler, D. Using programmer
-
written compiler extensio
ns to catch security

holes.
IEEE
Symposium on Security and Privacy
, pp. 143

159, 2002.

[22]

MITRE common vulnerabilities and exposures http://cve.mitre.org/cve/2007

[23]

McClure, R., Krüger, I.: SQL DOM: Compile Time Checking of Dynamic SQL Statements.

In: 27th IEEE

International Conference on Software Engineering, pp. 88
--
96. IEEE Press,

New York (2005)
.

Dinesh Chandra Mishra

et al

/ VSRD
International Journal of CS & IT Vol. 2 (4), 2012


Page
9

of 9


