Vous êtes sur la page 1sur 15

ATTACKING DDOS AT THE SOURCE

AIM OF PROJECT
The mainstay of the project is how to secure web applications using the
Spring Security framework and going to avoid existing problems in real world
technologies.

Existing System
Because burst traffic and high volume are the common characteristics of
App-DDoS attacks and flash crowds, it is not easy for current techniques to distinguish
them merely by statistical characteristics of traffic. Therefore, App-DDoS attacks may be
stealthier and more dangerous for the popularWebsites than the general Net-DDoS
attacks when they mimic (or hide in) the normal flash crowd.

Disadvantages
• Client side SSL(secure socket layer).
• Saving password in cookies.
• Transfer data to page to page.
• Not separation business logic
• Navigation problem

Proposed System
The detection of App-DDoS attacks during the flash crowd event. This
paper introduces a scheme to capture the spatial-temporal patterns of a normal flash
crowd event and to implement the App-DDoS attacks detection. Since the traffic
characteristics of low layers are not enough to distinguish the App-DDoS attacks from
the normal flash crowd event, the objective of this paper is to find an effective method to
identify whether the surge in traffic is caused by App-DDoS attackers or by normal Web
surfers.
Advantages
• Server side encryption
• Don’t save passwords to cookies
• Duplicate url.
• Avoid navigation problem.
• Don’t need sql knowledge.

RELATED WORK
Our literature survey has noted that researchers attempt to detect DDoS attacks
from three different layers: IP layer, TCP layer, and application layer. From all of these
perspectives, researchers are investigating various approaches to distinguish normal
traffic from the attack one. Here, we survey representative research from each
perspective.
Most DDoS-related research has focused on the IP layer.These mechanisms
attempt to detect attacks by analyzing specific features, e.g., arrival rate or header
information. For example, Cabrera et al. [12] used the management information base
(MIB) data which include parameters that indicate different packet and routing statistics
from routers to achieve the early detection. Yuan et al. [13] used the cross-correlation
analysis to capture the traffic patterns and then to decide where and when a DDoS
attack possibly arises. Mirkovic et al. [14] monitored the asymmetry of two-way packet
rates and to identify attacks in edge routers. Other statistical approaches for detection of
DDoS attacks includes IP addresses [15] and time-to-live (TTL) values [16].

The TCP layer is another main battlefield for detecting DDoS attack. For
example, authors [12] mapped ICMP, UDP, and TCP packet statistical abnormalities to
specific DDoS attacks based on MIB. Wang et al. [17] used the TCP SYN/FIN packets
for detecting SYN flooding attacks. In [18], DDoS attacks were discovered by analyzing
the TCP packet header against the welldefined rules and conditions and distinguished
the difference between
normal and abnormal traffic. Noh et al. [19] attempted to detect attacks by computing the
ratio of TCP flags (including FIN, SYN, RST, PSH, ACK, and URG) to TCP packets
received at a Web server.
However, little work has been done on the detection of App-DDoS attacks
because there were few such attacks in the past. Ranjan et al. [20] used statistical
methods to detect characteristics of HTTP sessions and employed rate-limiting as the
primary defense mechanism. Yen et al. [21] defended the application DDoS attacks with
constraint random request attacks by the statistical methods. Other researchers
combated the App-DDoS attacks by “puzzle,” see, e.g., [3]. Jung et al.’s work [5] is most
closely related to our own, as they used two properties to distinguish the DoS and
normal flash crowd: 1) a DoS event is due to an increase in the request rates for a small
group of clients
while flash crowds are due to increase in the number of clients and 2) DoS clients
originate from new client clusters as compared to flash crowd clients which originate
from clusters that had been seen before the flash event.

App-DDoS ATTACKS
In our opinion, the DDoS attack detection approaches in different scenario can be
clustered as:
1) Net-DDoS attacks versus stable background traffic;
2) Net-DDoS attacks versus flash crowd (i.e., burst background traffic);
3) App-DDoS attacks versus stable background traffic;
4) App-DDoS attacks versus flash crowd. The first two scenarios have been

well studied and can be dealt with by most existing DDoS detection schemes (e.g., those
presented in Section II) while the other two groups are quite different from the previous
ones.

Besides the flooding attack pattern, App-DDoS attacks may focus on exhausting the
server resources such as Sockets, CPU, memory, disk/database bandwidth, and I/O
bandwidth. Research [22] has found, with increasing computational complexity in
Internet applications and larger network bandwidth, that server resources may become
the bottleneck of those applications. Thus, the App-DDoS attacks may cause more
serious problems in the high-speed Internet than in the past.

The first characteristic of App-DDoS attacks is that the application-layer requests


originating from the compromised hosts are indistinguishable from those generated by
legitimate users. Unlike the Net-DDoS attacks, App-DDoS attacks do not necessarilyrely
on inadequacies in the underlying protocols or operating systems; they can be mounted
with legitimate requests from legitimately connected network machines. Usually, App-
DDoS attacks utilize the weakness enabled by the standard practice of opening services
such as HTTP and HTTPS (TCP port 80 and 443) through most firewalls to launch the
attack. Many protocols and applications, both legitimate and illegitimate, can use these
openings to tunnel through firewalls by connecting over a standard TCP port 80 (e.g.,
Code Red virus) or encapsulating in SSL tunnels (HTTPS). Attack requests aimed at
these services may pass through the firewall without being identified. Furthermore,
attackers may request services to the point where other clients are unable to complete
their transactions or are inconvenienced to the point where they give up trying.

The Problem with the Servlet Specification


Many web applications have use cases that do not naturally fit into the scopes
provided by the Servlet specification. These use cases often span more than one
page but do not require the longevity of the session. Users may also perform
different use cases per browser session or even execute the same use case over
and over. In this scenario, data associated with one use case execution needs to
be cleaned up before a new execution can begin, which is something the session
cannot do. In essence, the Servlet specification is missing the concept of a
conversational scope to support the execution of use cases that span multiple
pages Greatly increased memory footprint per user. Because each user’s
session is stored in memory, the serving capacity of each server is reduced. This
is compounded by the fact that out-of-date context (e.g., ended or expired
conversations) still exists in the session
and needs to be manually removed.
.
STRUTS 2 AND SPRING MVC

How would you do this today with Struts 2 AND Spring MVC?

Secure Sockets Layer (SSL)


Currently, most e-businesses use SSL for secure online transactions, although
SSL is not designed specifically for securing transactions. Rather, SSL secures World
Wide Web connections.

The Secure Sockets Layer (SSL) protocol, developed by Netscape


Communications, is a nonproprietary protocol commonly used to secure communication
between two computers on the Internet and the Web.20 SSL is built into many Web
browsers, including Netscape Communicator and Microsoft Internet Explorer, as well as
numerous other software products. It operates between the Internet’s TCP/IP
communications protocol and the application software

HTTP Secure
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer
Protocol with the SSL/TLS protocol to provide encryption and secure identification of
the server. HTTPS connections are often used for payment transactions on the
World Wide Web and for sensitive transactions in corporate information systems.

The main idea of HTTPS is to create a secure channel over an insecure network. This
ensures reasonable protection from eavesdroppers and man-in-the-middle attacks,
provided that adequate cipher suites are used and that the server certificate is verified
and trusted.

The trust inherent in HTTPS is based on major certificate authorities which come pre-
installed in browser software (this is equivalent to saying "I trust certificate authority (e.g.
VeriSign/Microsoft/etc.) to tell me who I should trust"). Therefore an HTTPS connection
to a website can be trusted if and only if all of the following are true:

1. The user trusts the certificate authority to vouch only for legitimate websites
without misleading names.
2. The website provides a valid certificate (an invalid certificate shows a warning in
most browsers), which means it was signed by a trusted authority.
3. The certificate correctly identifies the website (e.g. visiting https://somesite and
receiving a certificate for "Somesite Inc." and not "Shomesite Inc." [see #2]).
4. Either the intervening hops on the internet are trustworthy, or the user trusts the
protocol's encryption layer (TLS or SSL) is unbreakable by an eavesdropper.

Basic and Digest


Basic authentication, as its name implies, is the most basic form of authentication
available to Web applications. It was first defined in the HTTP specification itself and it is
by no means elegant, but it gets the job done. Simplicity has its advantages, at least
according to the KISS principle (keep it simple, stupid). Basic authentication has its fair
share of security problems and the problems are well documented. Let’s first describe
how Basic authentication works, then discuss security vulnerabilities and how people
work with the limitations of Basic authentication. Basic authentication begins with a client
making a request to the Web server for a protected resource, without any authentication
credentials. The server will reply with an access denied message containing a WWW-
Authenticate header requesting Basic authentication credentials. Most Web browsers
contain routines to deal with such requests automatically, by prompting the user for a
username and a password as shown in Figure 5-1. Note that this is a separate operating
system window instantiated by the browser, and not an HTML form. Included in this
prompt is a request for the “realm,” which is just
a string assigned by the server (most implementations typically set the realm to the
hostname or IP address of the Web server by default).
Forms-Based Authentication
In contrast to the mechanisms we’ve discussed to this point, Forms-based
authentication does not rely on features supported by the basic Web protocols like HTTP
and SSL (such as Basic auth or client-side certifications). It is a highly customizable
authentication mechanism that uses a form, usually composed of HTML with <FORM>
and <INPUT> tags delineating fields for users to input their username/password
information. After the data is input via HTTP (or SSL), it is evaluated by some server-
side logic and, if the credentials are valid, some sort of token is given to the client
browser to be reused on subsequent requests. Because of its highly customizable and
flexible nature, Forms-based authentication is probably the most popular authentication
technique deployed on the Internet. However, since it doesn’t rely on any features of
standardized Web protocols, there is no standardized way to perform Forms-based
authentication.
Hacking tools
Sam Spade http://www.samspade.org
netcat http://www.atstake.com/research/
tools/index.html
fscan http://www.foundstone.com
nmap http://www.insecure.org
sslproxy http://www.obdev.at/products/
ssl-proxy/
openssl http://www.openssl.org/
stunnel http://www.stunnel.org/
Whois
European IP Address Allocation http://www.ripe.net/
Many web applications have some particular URLs that are critically important and
private. You must secure these URLs by preventing unauthorized access to them. A
secure application requires its users to log in before they can access certain secure
functions. This is especially important for web applications running on the open Internet
because hackers can easily reach them. Most web applications have to provide a way
for users to input their credentials to log in. When a user attempts to log into your
application to access its secure resources, you have to authenticate the user’s principal
and grant authorities to this user. You would like to manage a simple UI flow in a Spring
MVC application using Spring Web Flow.
Rational AppScan

If you use networked or Web applications to collect or exchange sensitive data, your job
as a security professional is harder now than ever before. Finding ways to extend
security analysis across more testers in the application security process and employing
multiple testing techniques will result in higher-quality, more secure applications. More
importantly, it can save you considerably. There have been numerous documented
cases of companies that spent millions of dollars recovering from a cyber-attack and
finding vulnerabilities in your production environment can cost 100-times more than had
the issue been uncovered during development. Rational AppScan offers static and
dynamic security testing in all stages of application development. Rational AppScan
products provide:
2.4 MOTIVATION
Solution
Spring Security enables you to secure a web application’s URL access in a declarative
way through simple configuration. It handles security by applying servlet filters to HTTP
requests. You can configure these filters in Spring’s bean configuration files using XML
elements defined in the Spring Security schema. However, as servlet filters must be
registered in the web deployment descriptor to take effect, you have to register a
Delegating FilterProxy instance in the web deployment descriptor, which is a servlet
filter that delegates request filtering to a filter in Spring’s application context.

Spring Security supports multiple ways for users to log into a web
application. It supports form-based login by providing a default web page that contains a
login form. You can also provide
a custom web page as the login page. In addition, Spring Security supports HTTP Basic
authentication by processing the Basic authentication credentials presented in HTTP
request headers. HTTP Basic authentication can also be used for authenticating
requests made with remoting protocols and web services.

Spring Security supports multiple ways of authenticating users and includes built-in
provider implementations for them. You can easily configure these providers with the
built-in XML elements. Most common authentication providers authenticate users
against a user repository storing user details (e.g., in an application’s memory, a
relational database, or an LDAP repository). When storing user details in a repository,
you should avoid storing user passwords in clear text because they are vulnerable to
hackers. Instead, you should always store encrypted passwords in your repository. A
typical way of encrypting passwords is to use a one-way hash function to encode the
passwords. When a user enters a password to log in, you apply the same hash function
to this password and compare the result with the one stored in the repository. Spring
Security supports several algorithms for encoding passwords (including MD5 and SHA),
and provides built-in password encoders for these algorithms. If you retrieve a user’s
details from a user repository every time a user attempts to log in, your application may
incur a performance impact. This is because a user repository is usually stored remotely,
and it has to perform some kinds of queries in response to a request. For this reason,
Spring Security supports caching user details in local memory and storage to save you
the overhead of performing remote queries.

The Flow Is King


Firstly, Spring Web Flow treats conversational scope as a first-level citizen. It
was designed from the ground up with that as the centerpiece. The core artifact within
Spring Web Flow is the flow (or conversation). It is this flow definition that defines a
blueprint for a conversation with the user. Conversations can execute in parallel without
intruding on each other, and when the conversation has finished, all allocated resources
are automatically cleaned up.

Vous aimerez peut-être aussi