You are on page 1of 13

INSTITUTE OF ROAD AND TRANSPORT TECHNOLOGY

ERODE

NETWORK SECURITY

By,

K. KIRUTHIKA

TM.MADHU PRIYADHARSHINI

kiruthikakamaraj29@gmail.com

7373250067

ABSTRACT:
Application-level Web security refers to vulnerabilities inherent in the code of a Web-application
itself (irrespective of the
technologies in which it is implemented or the security of the Web-server/back-end database on
which it is built). In the last few
months, application-level vulnerabilities have been exploited with serious consequences:
Hackers have tricked e-commerce sites into shipping goods for no charge, usernames and
passwords have been harvested, and confidential information (such as addresses and credit-card
numbers) has been leaked. In this paper, we investigate new tools and techniques which address
the problem of
application-level Web security. Such,
▪ Describe a scalable structuring mechanism facilitating the abstraction of security policies
from large Web-applications developed in heterogeneous multiplatform environments;
▪ Present a set of tools which assist programmers in developing secure applications which are
resilient to a wide range of common attacks; and report results and experience arising
from our implementation of these techniques.
Security is too critical to leave up to individual coders. The Secure Web Applications enforces
centralized security policies across entire Web sites.Although traditional firewalls have
effectively prevented network-level attacks, most future attacks will be at the application level,
where current security mechanisms are woefully inadequate.

▪ Application-level security vulnerabilities are inherent in a Web application’s code, regardless


of the technology in which the application is implemented or the security of the Web server
and backend database on which it is built. A recent advisory published by Internet Security
Systems.

The paper aims to provide a means of understanding the web security and exploring techniques
available for complementing your security over the web needs.

INTRODUCTION:
Security is a measurement, not a characteristic.It is unfortunate that many software projects list
security as a simple requirement to be met. Is it secure? This question is as subjective as asking
if something is hot. Security must be balanced with expense and usability. It is not uncommon
that steps taken to increase the security of a web application also decrease the usability.
Passwords, session timeouts, and access control all create obstacles for a legitimate user.
Sometimes these are
necessary to provide adequate security, but there isn't one solution that is appropriate for every
application.

Security:
What is being protected?
After identifying assets, identify what it is
about them that needs protecting.
•Secrecy: protection against unauthorised
access, viewing, copying, etc.
•Integrity: Protection against unauthorised
modification and deletion.
•Availability: Protection against attacks
that render the asset unusable.
DATA FILTERING:
As stated previously, data filtering is the cornerstone of web application security, and this is
independent of programming language or platform. It involves the mechanism by which you
determine the validity of data that is entering and exiting the application, and a good software
design can help developers to:
l. Ensure that data filtering cannot be bypassed,
2. Ensure that invalid data cannot be mistaken for valid data, and
3. Identify the origin of data.

Session Fixation:
The most crucial piece of information for an attacker is the session identifier, because this is
required for any impersonation attack. There are three common methods used to obtain a valid
session identifier:
● Prediction
● Capture
● Fixation
Prediction refers to guessing a valid session identifier. With PHP's native session mechanism,
the session identifier is extremely random, and this is unlikely to be the weakest point in your
implementation.
Capturing a valid session identifier is the most common type of session attack, and there are
numerous approaches.Because session identifiers are typically propagated in cookies or as GET
variables, the different approaches focus on attacking these methods of transfer.
Fixation is the simplest method of obtaining a valid session identifier. While it's not very
difficult to defend against, if your session mechanism consists of nothing more than
session_start(), you are vulnerable.

Session Hijacking:
Arguably the most common session attack, session hijacking refers to all attacks that attempt to gain
access to another user's session. As with session fixation, if your session mechanism only consists of
session_start(), you are vulnerable, although the exploit isn't as simple. Rather than focusing on how to
keep the session .
Web security:
If software could properly validate input and output, most web attacks wouldn’t work.We can
secure web applications by validate input and output.This sometimes requires a
demonstration.this is possible by making programmers to stop writing bugs.

Who Wants To Hack Your Website?

● Most hackers are like “INTERNET SCAVENGERS” .They find valuable things and
trade them. Passwords, CC#s, Pornography, etc.

● .Launching point for other attacks Bots, Zombies, Proxies.

● Redirects.Others are financially or politically motivated.


If you know one of the keys, you cannot easily calculate what the other one is. As a result, in a
‘public key system’ you have the following:
● A public key
● A corresponding (and unique) private key
● A digital certificate

A digital certificate is information referring to a public key that has been digitally signed by a
Certificate Authority (CA). The information normally found in a certificate conforms to the ITU
(IETF) standard X.509 v3. Certificates conforming to that standard include information about the
published identity of the owner of the corresponding private key, the key length, the algorithm
used, and associated algorithms, dates of validity of the certificate and the actions the key can be
used for. While PKI infrastructure administration can be complex, USPTO eliminates this
complexity
by managing it for registered EFS-Web users.

Database Security:
Isolate Database Server–Database should be separate from web serverand use a firewall to
severely restrict access.Encrypt database connections by hardening the Database Server
● CIS SQL Hardening Guide

● Configure Users and permissions carefully

● Use separate SQL accounts for Users and Admins

● Make sure to set administrative password


● Use parameterized SQL or Server Side SQL
● XSS is a Serious Threat to Admins:
Normally, XSS is exploited by tricking users.Script can be injected into admin browsers.

Sql injection:

SQL injection attacks are extremely simple to defend against, but many applications are still
vulnerable.Depending on the database you are using, it might be possible to send multiple
queries to the database server in a single call. Thus, a user can potentially terminate the existing
query with a semicolon and follow this with a query of the user's choosing.

If your database allows it (MySQL does), put single quotes around all values in your SQL
statements, regardless of the data type.
sometimes valid data can unintentionally interfere with the format of the SQL statement itself.
Use
mysql_escape_string() or an escaping function native to your particular database. If there isn't a
specific one,
addslashes() is a good last resort.

Encoding Attacks:
Character encoding allows data in many forms
● ASCII, UTF-8, UTF-16, urlencode, modified UTF-8

● Double encoded, Triple encoded


● Normalize all input

● Use existing libraries to filter content


WEBSITE SECURITY ISSUES:
1. Validation of input and output data:
All data used by the website (from users, other servers, other websites and internal systems) must
be validated for type (e.g. numeric, date, string), length (e.g. 200 characters maximum, or a
positive integer) and syntax (e.g. product codes begin with 2 letters and are followed by 5 digits)
and business rules (e.g. televisions can only cost between £100 and £2000, an order can
mcontain at most 20 items, daily credit limit must not
be exceeded). All data written as output (displayed) needs to be safe to
view in a browser, email client or other software and the integrity of any
data that is returned must be checked. Utilising Asynchronous JavaScript
and XML (AJAX) or Adobe Flex increase complexity and the possible attack
vectors.
2. Direct data access (and theft):
If data exists, it can potentially be viewed or extracted. Avoid storing data that you do not need
on the website and its database(s) – for
example some data relating to payment cards should never be stored. Poorly developed systems
may allow access to data through SQL injection compromises, insufficient input and output data
validation.
3. Data poisoning:
If user’s can amend or delete data inappropriately and this is then used to
update your internal systems, business information is being lost. This can be hard to detect and it
is important that the business rules are examined and enforced to validate data changes to ensure
poisoning is not
occurring. If poisoning is not detected until well after it has occurred, it may be impossible to
recover the original data.
4. Malicious file execution:
Uploaded files or other data feeds may not be what they seem. Never allow user-supplied input
to be used in any file name or path (e.g. URLs or file system references). Uploaded files may
also contain a malicious
payload so should not be stored in web accessible locations.
5. Authentication and session management:
Websites rely on identifying users to provide access permissions to data and functions. If
authentication (verification of identity, registration and logging in), authorisation (granting
access rights) and session management (keeping track of the identity of a logged in user while
they browse a
website) can be circumvented or altered, a user could access resources they are not allowed to.
Beware especially of how password reminders, remember-me, change password, log out and
updating account details are handled, how session tokens are used and always have login forms
on
dedicated and encrypted (SSL) pages.
6. System architecture and configuration:
The information system architecture model should address the sensitivity of data identified
during the requirements and specification phase of a website project. This may entail having
separate web, application and database servers or involve clustering, load balancing or
virtualisation.
Additional security issues can be created through the way the live environment is configured.
Sufficient and safe logging,monitoring and alerting facilities need to be built in to allow audit.
7. Phishing:
Phishing, where users are conned into believing some other entity is or
belongs to your own organisation (email messages and websites are the most common
combination), is best tackled through user education but the way the website is designed, its
architecture and how it communicates with users can reduce the risk.
8. Denial of service:
Whilst malicious users might try to swamp the web server with a vast number of requests or
actions that degrade its performance (filling up logs, uploading large files, undertaking tasks that
require a lot of memory repeatedly) denial of service attacks include locking out valid user
accounts or be caused by coding problems (e.g. memory leaks, resources not being released).

9. System information leakage:


Web servers, errors, staff, partner organisations, search engines and
rubbish can all be the source of important information about your website technologies, business
logic and security methods. An attacker can use such information to their advantage so it is
important to avoid system information leakage as far as possible.
10. Error handling:
Exceptions such as user data validation messages, missing pages and server errors should be
handled by the code so that a custom page is displayed that does not provide any system
information to the user . Logging and alerting of unusual conditions should be enabled and these
should allow subsequent audit.

Solutions for WEB SECURITY:


There are a number of ideas to fix this two security problems. The basic approach is to create a
library of ASP functions which can be used without much hassle. The advantage of this is that it
can be used very easily. But
it’s not the best way, because you need to think of it every time you read some request. The one
and only place where you forget to use this functions might be the door for an attacker. The
other major disadvantage is

that this requires a system for code sharing to ensure that every Web application uses current
functions . Combined with the ASP functions it’s possible to create a checker tool that reads the
source files on the server and tries to detect the parameters which aren’t checked. This could
even be automated using command line options and/or a configuration.
GUIDE LINE FOR WRITING WEB APPLICATIONS: WritingSecure Web

• Never use input you get from the client without sanitizing it
– Enforcing data types
• Only numbers?
• Only letters?
• Formatting (credit cards, telephone numbers)
– Length restrictions (TinyDisk file system)
– Escaping characters like < “ ‘ | ; > to avoid SQL injection and XSS attacks input validators
should be implemented on both sides of a web application. Client-side validation should exist
solely for performance issues. Server-side validators are the only way to enforce any limits
Frontend code should properly represent backend code .Backend code for an HTML FORM that
uses POST should only read values that were posted. (Request.Form vs. Request.QueryString,
etc) Over engineering is very bad. Applications should only provide enough functionality to
work . If you have static content, do not use scripting technologies (ASP, PHP, JSP, etc) to serve
it
– LDAP directory vs. full SQL-driven relational database
Conclusions:
The following three points probably summarise this talk fairly well:
•Security is about protecting privacy, integrity or availability of assets from a malicious attacker.
•Many attacks can be thwarted by good validation, but not all of them.
•The effort expended to protect a system should relate to the cost of it being exploited.
References:
[5] Cgisecurity.com. The cross site scripting faq..
[2] CERT. Advisory CA-2000-02 malicious HTML tags embedded in client Web
requests.
www.howstuffworks.com
www.cert.org
www.cgisecurity.com

You might also like