Professional Documents
Culture Documents
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.
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.
● Most hackers are like “INTERNET SCAVENGERS” .They find valuable things and
trade them. Passwords, CC#s, Pornography, etc.
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
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
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