1. Denial of Service (DoS)
This attack aims at preventing, for legitimate users, authorized access to a system
resource or the delaying of system operations and functions. The attacker sends a few
messages crafted in a specific manner that take advantage of the given vulnerability.
Another way is to send a vast number of messages that consume some key resource at the
target such as bandwidth, CPU time, memory, etc. The target application, machine, or
network spends all of its critical resources on handling the attack traffic and cannot serve
for its legitimate clients. The attack would last only as long as the attack is active.
Distributed Denial of Service Attack (DDoS)
DDoS are distributed Denial of Service attacks that achieve larger magnitude by
launching coordinated attacks by using a framework of “handlers” and “agents”. A DDoS
is innovative in the form of coordination of the attack, not in the attacker’s aim.
Characteristics of DDoS
DDoS Attack is a large-scale and coordinated attack on the availability of services of a
victim system. The services under attack are those of the “primary victim,” while the
compromised systems used to launch the attack are often called the “secondary victims”.
This makes it difficult to detect because attacks originate from several IP addresses. If a
single IP address is attacking a company, it can block that address at its firewall. If it is
30,000, this is extremely difficult. Perpetrator is able to multiply the effectiveness of the
Denial of Service significantly by harnessing the resources of multiple unwitting
accomplice computers which serve as attack platforms.
Smurf
The attacker would send a lot of ICMP echo request packets to a broadcast address,
wherein the source address of the packets are set to the address of victim host ( instead of
the attacker’s address), which is called spoofed source address. The requested hosts
would respond the victim’s host by sending ICMP echo reply packets. The attacked host
is flooded with ICMP reply packets and then can’t serve for other legitimate users.
Buffer overflow
Buffer overflow occurs any time the program writes more information into the buffer
than the space allocated in the memory. The attacker can overwrite the data that controls
the program execution path and hijack the control of the program to execute the
attacker’s code instead of the process code. Sending email messages that have
attachments with 256-character file names can cause buffer overflow.
Teardrop
IP requires that a packet that is too large for the next router to handle should be divided
into fragments. The attacker's IP puts a confusing offset value in the second or later
fragment. If the receiving operating system is not able to aggregate the packets
accordingly, it can crash the system. It is a UDP attack, which uses overlapping offset
fields to bring down hosts.

2. Ping of Death
The attacker deliberately sends an IP packet larger than the 65,536 bytes allowed by the
IP protocol. Fragmentation allows a single IP packet to be broken down into smaller
segments. The fragments can add up to more than the allowed 65,536 bytes. The
operating system, unable to handle oversized packets freezes, reboots, or simply crashes.
The identity of the attacker sending the oversized packet can be easily spoofed.
SYN
The attacker sends bogus TCP SYN requests to a victim server. The host allocates
resources (memory sockets) to the connection. Prevents the server from responding to the
legitimate requests. This attack exploits the three-way handshake. Malicious flooding by
large volumes of TCP SYN packets to the victim’s system with spoofed source IP
addresses can cause DoS.
Countermeasures
Implement router filters.
If they are available for your system, install patches to guard against TCP SYN flooding.
Disable any unused or unneeded network services.
Enable quota systems on your operating system if they are available.
Observe your system performance and establish baselines for ordinary activity. Use the
baseline to gauge unusual levels of disk activity, CPU usage, or network traffic.
Use Tripwire or a similar tool to detect changes in configuration information or other
files.
Invest in redundant and fault-tolerant network configurations.
Establish and maintain regular backup schedules and policies, particularly for important
configuration information.
Establish and maintain appropriate password policies, especially access to highly
privileged accounts such as UNIX root or Microsoft Windows NT Administrator.
DDoS countermeasure
Configure routers to filter and limit traffic (ICMP, SYN, UDP, etc).
Deploy firewalls at the boundaries of your network and filtering system must be able to
distinguish harmful uses of a network service from legitimate uses.
Install IDS (Intrusion Detection Systems) capable of detecting.

3. Buffer Overflow
Buffer overflow is caused by an attacker making the program write more data into the
buffer on memory than the buffer can hold, and the over run data in that buffer overflows
onto another adjacent memory space that is used for other purposes. The problem is that
no automatic bounds-checking is made while passing data. Buffer overflow allows the
attackers to run their own codes on the attacked system.
Stack Based overflow
The stack on a memory is used to store temporary information. The attacker would add
more information into the variable, when the program runs the variable assigned in the
stack on memory exceed the limit and overflow occurs. The attacker can change the
return address with a pointer to attacker’s executable codes in the stack. When a function
call is executed, the address of the instruction is put onto the stack to be saved so that the
function knows where to return control. Then the attacker’ code gain control and execute
his programs.
A buffer overflow occurring in the heap data area is referred to as a heap overflow and is
exploitable in a different manner to that of stack-based overflows. Memory on the heap is
dynamically allocated by the application at run-time and typically contains program data.
Exploitation is performed by corrupting this data in specific ways to cause the application
to overwrite internal structures such as linked list pointers. The canonical heap overflow
technique overwrites dynamic memory allocation linkage (such as malloc meta data) and
uses the resulting pointer exchange to overwrite a program function pointer.
Heap based overflow
The heap, a space on memory is utilized and assigned dynamically by the application at
runtime. Dynamic variables are assigned on the heap with functions like malloc interface.
Program data on heap is overflowed by an attacker to overwrite other dynamic variables.
Shellcode is a method to exploit stack-based overflows
Shellcodes exploit computer bugs in how the stack is handled
In computer security, a shellcode is a small piece of code used as the payload in the
exploitation of a software vulnerability. It is called "shellcode" because it typically starts
a command shell from which the attacker can control the compromised machine.
Shellcode is commonly written in machine code, but any piece of code that performs a
similar task can be called shellcode.
Libsafe is a library which re-writes some sensitive libc functions (strcpy, strcat, sprintf,
vsprintf, getwd, gets, realpath, fscanf, scanf, sscanf) to prevent any overflow caused by a
misuse of any one of them.
It launches alerts when an overflow attempt is detected.
Libsafe intercepts the calls to the unsafe functions and uses its own implementation of the
function instead.

4. While keeping the same semantic, it adds detection of the bound violations.
Buffer Overflow Countermeasure
Manually audit the codes to make sure the stacks are not altered when the program is
running. One good way is to disable the stack from executing other extra instructions. But
manage the computer to use heap and stack for only data. Compilers should be
programmed to do bound checks to process only appropriate inputs. Return Address
Defender (RAD) is a simple patch for the compiler that automatically creates a safe area
to store a copy of return addresses. After that, RAD automatically adds protection code
into applications and compiles them to defend programs against buffer overflow attacks.
Using a well supported and safe library could enable the programs run secure without
overwriting.
A SQL injection attack consists of insertion or "injection" of a SQL query via the input
data from the client to the application. A successful SQL injection exploit can read
sensitive data from the database, modify database data (Insert/Update/Delete), execute
administration operations on the database (such as shutdown the DBMS), recover the
content of a given file present on the DBMS file system and in some cases issue
commands to the operating system. SQL injection attacks are a type of injection attack, in
which SQL commands are injected into data-plane input in order to effect the execution
of predefined SQL commands.
Exploiting sql injection
It exploits web applications using client-supplied sql queries.
It enables an attacker to execute unauthorized SQL commands.
It also takes advantage of unsafe queries in web applications and builds dynamic SQL
queries.
For example, when a user logs onto a web page by using a user name and password for
validation, a SQL query is used.
However, the attacker can use SQL injection to send specially crafted user name and
password fields that poison the original SQL query.
Try to look for pages that allow a user to submit data, for example: a log in
page, search page, feedback, etc
Look for HTML pages that use POST or GET commands
If POST is used, you cannot see the parameters in the URL

5. Check the source code of the HTML to get information
For example, to check whether it is using POST or GET, look for the <Form>
tag in the source code
<Form action=search.asp method=post>
<input type=hidden name=X value=Z>
</Form>
Hacker breaks into the system by injecting malformed SQL into the query
•strQry = "SELECT Count(*) FROM Users WHERE UserName='" + txtUser.Text + "'
AND Password='" + txtPassword.Text + "'";
Original SQL Query:
•SELECT UserName='Paul' In the case of the user entering a valid user name of "Paul"
and a password of "password", strQry becomes:
Count(*) FROM Users WHERE AND Password='password'
But when the hacker enters ' Or 1=1 -- the query now
becomes:
•SELECT Count(*) FROM Users WHERE UserName='' Or 1=1 --' AND Password=''
Because a pair of hyphens designates the beginning of a
comment in SQL, the query becomes simply:
•SELECT Count(*) FROM Users WHERE UserName='' Or 1=1
Blind SQL injection is a hacking method that allows an
unauthorized attacker to access a database server
It is facilitated by a common coding blunder: program
accepts data from a client and executes SQL queries without
validating client’s input
Attacker is then free to extract, modify, add, or delete
content from the database
Hackers typically test for SQL injection vulnerabilities by
sending application input that would cause server to
generate an invalid SQL query
To secure an application against SQL injection, developers must never allow
client-supplied data to modify the syntax of SQL statements
The best protection is to isolate the web application from SQL altogether
All SQL statements required by application should be in stored procedures
and kept on database server
Application should execute stored procedures using a safe interface such as
JDBC’s CallableStatement or ADO’s Command Object
If arbitrary statements must be used, use PreparedStatements
Both PreparedStatements and stored procedures compile SQL statement
before user input is added, making it impossible for user input to modify
actual SQL statement

6. Minimize the privileges of database connections
Disable verbose error messages
Protect the system account “sa”
Audit source codes
• Escape single quotes
• Input validation
• Reject known bad input
• Input bound checking
Never trust user input
• Validate all textbox entries using validation controls, regular expressions, code, and
so on
Never use dynamic SQL
• Use parameterized SQL or stored procedures
Never connect to a database using an admin-level account
• Use a limited access account to connect to the database
Do not store secrets in plain text
• Encrypt or hash passwords and other sensitive data; you should also encrypt
connection strings
Exceptions should divulge minimal information
• Do not reveal too much information in error messages; use custom errors to display
minimal information in the event of an unhandled error; set debug to false
Cross-site scripting (XSS)
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in
web application that enables malicious attackers to inject client-side script into web pages
viewed by other users. An exploited cross-site scripting vulnerability can be used by
attackers to bypass access controls such as the same origin policy. Their impact may
range from a petty nuisance to a significant security risk, depending on the sensitivity of
the data handled by the vulnerable site, and the nature of any security mitigations
implemented by the site's owner.
Cross-site scripting holes are web application vulnerabilities that allow attackers to
bypass client-side security mechanisms normally imposed on web content by modern
browsers. By finding ways of injecting malicious scripts into web pages, an attacker can
gain elevated access privileges to sensitive page content, session cookies, and a variety of
other information maintained by the browser on behalf of the user.

7. Non-persistent XSS
These holes show up when the data provided by a web client, most commonly in HTTP
query parameters or in HTML form submissions, is used immediately by server-side
scripts to generate a page of results for that user, without properly sanitizing the response.
If one searches for a string, the search string will typically be redisplayed on the result
page to indicate what was searched for. If this response does not properly escape or reject
HTML control characters, a cross-site scripting flaw will ensue.
It is important to realize, however, that a third-party attacker may easily place hidden
frames or deceptive links on unrelated sites and cause victims' browsers to navigate to
URLs on the vulnerable site automatically and in such a case, the attacker can intrude
into the security context that rightfully belonged to the victim.
Persistent XSS
The persistent (or stored) XSS vulnerability is a cross-site scripting flaw: it occurs when
the data provided by the attacker is saved by the server, and then permanently displayed
on "normal" pages returned to other users in the course of regular browsing, without
proper HTML escaping.
An attacker's malicious script is rendered automatically, without the need to individually
target victims or lure them to a third-party website. Particularly in the case of social
networking sites, the code would be further designed to self-propagate across accounts,
creating a type of a client-side worm.
In some cases, the attacker may not even need to directly interact with the web
functionality itself to exploit such a hole. Any data received by the web application (via
email, system logs, etc.) that can be controlled by an attacker could become an injection
vector.
DOM-based vulnerabilities
This is the standard model for representing HTML or XML contents which is called
Document Object Model (DOM).
DOM-based vulnerabilities occur in the content processing stages performed by the
client, typically in client-side JavaScript. JavaScript programs manipulate the state of a
web page and populate it with dynamically-computed data primarily by acting upon the
DOM. A typical example is a piece of JavaScript accessing and extracting data from the
URL via the location.* DOM, or receiving raw non-HTML data from the server via XML
http request, and then using this information to write dynamic HTML without proper
escaping, entirely on client side.
Content validation, escaping and filtering

8. One way to eliminate some XSS vulnerabilities is to validate and reject undesirable
characters in input fields using a blacklist, whitelist or combination of both. Another way
is to escape all untrusted data using a method appropriate for the output context.
Many operators of particular web applications (e.g. forums and webmail) wish to allow
users to utilize some of the features HTML provides, such as a limited subset of HTML
markup. To achieve this while preventing cross-site scripting flaws, some web
applications attempt to identify malicious HTML constructs, and remove or rewrite them
to prevent attacks.
Cookie security
Many web applications rely on session cookies for authentication between individual
HTTP requests, and because client-side scripts generally have access to these cookies,
simple XSS exploits can steal these cookies.
To avoid this particular threat, many web applications tie session cookies to the IP
address of the user who originally logged in, and only permit that IP to use that cookie.
Disabling scripts
Some web applications are written to operate completely without the need for client-side
scripts. This allows users to have chance to disable scripting in their browsers before
using the application. In this way, even potentially malicious client-side scripts could be
inserted unescaped on a page, and users would not be susceptible to XSS attacks.
Some browsers or browser plugins can be configured to disable client-side scripts on a
per-domain basis. Functionality that blocks all scripting and external inclusions by
default and then allows the user to enable it on a per-domain basis is more effective. The
Firefox NoScript extension enables users to allow scripts selectively from a given page
while disallowing others on the same page.