ITIS 4166/5166 Network Based
Application Development
Anita Raja
Spring 2006
Security in Network-Based
Applications
Agenda
Network Security.
Application Security.
Web Services Security.
References
Open Web Application Security Project (OWASP)
www.owasp.org
Oasis (Organization for the Advancement of
Structured Information Standards)
http://www.oasis-open.org/specs/index.php#wssv1.1
Network Security
Serious threats to Network
Security
Customized virus will evade popular virus scan
programs:
Virus immunology techniques may help, but there is no guarantee!
Customized trojans.
IDS and popular tools are generally ineffective.
Attack techniques:
Be noisy.
Be quiet.
Denial of service
Noisy sync flooding.
Typical denial of service starts with a hacked
account (e.g. AOL surveys!).
Synchronized attacks uses multiple staging
points, very difficult to detect and deal with.
Best defenses
Educate users about password and common sense
security precautions.
Don’t execute active MIME contents:
Christmas cards etc.
Security is a system engineering problem:
the system is only as secure as its weakest link.
Clear risk assessment.
Turn off unwanted services:
simplify, simplify and simplify.
Best defenses …
Don’t blindly use defaults!
Upgrade software.
Don’t make information easily available.
User education and more user education.
Application Security
Web applications
Web applications are pervasive:
driver license renewal, grade entry, banking,
trading stocks, airline reservation, hotel
reservation, buying books, library.
They are typically outside of firewalls.
Web application threats
DataDatabase Backend systems frontend systems Web Server User interface code
Invalid input Code Data Browser
Flaws in Code, Web server, Front end system, Back end system or database ==>
unauthorized access of privileged accounts, the OS, network, or sensitive data and may result in denial of services.
Common Hack Attacks
1.
Hidden Field Manipulation
2.Parameter Tampering
3.Malicious Values
4.Cookie Poisoning
5.Stealth Commanding
Hidden Field Manipulation
Open the html page within HTML editor.
Locate the hidden field (e.g., “<type=hidden name=price
value=99.95>”.
Modify content (e.g., “<type=hidden name=price
value=1.00>”.
Save the html file locally and browse it.
Click buy button to perform electronic shop lifting via
hidden manipulation.
Parameter Tampering
Failure to confirm the correctness of CGI parameters
embedded in a hyper link can be easily used to break the
site security.
a search CGI may accept a “template” parameter
Search.exe?template=result.html&q=security
By replacing the template parameter, one may be able to
obtain access to any file, e.g.
Search.exe?template=/etc/passwd&q=security
Input Malicious Values
Original / Attacked Account File
Newly created user Injected user with admin priv.
Cookie Modification
Gain Access of Other User
Stealth Commanding
The use of server side executions (e.g. “eval” or “system” Perl commands, SQL queries) enable someone to plant Trojan-horses in form submissions and run malicious or unauthorized commands:
Example : Postcard site.
User fills in a postcard sending form, including the recipient name.
Site emails the recipient with the postcard.
CGI used for this purpose was written in Perl, and it had the following statement in it: open (MAIL, "|$mailprog $recipient”).
Replacing $recipient with "[email protected]</etc/passwd," the hacker will be mailed the password file.
Shell commands can be executed as well by sending "x;rm -r /", deleting
the entire site.
Web Application Security
Web application opens channels for HTTP requests.
Attacks hidden within legal HTTP application requests
will bypass firewalls, filters, intrusion detection.
Secure web sites (https/ssl) only protects the channel.
Web application code needs to be part of an
organization’s security perimeter.
OWASP Top 10 Web Application
Vulnerabilities
Insecure Configuration Management A10
Denial of Service A9
Insecure Storage A8
Improper Error Handling A7
Injection Flaws A6
Buffer Overflows A5
Cross-Site Scripting (XSS) Flaws A4
Broken Authentication & Session Management A3
Broken Access Control A2
Unvalidated Input A1
Common vulnerabilities that lead to compromise of information:
1. Unvalidated Input
Information from web requests is not validated or filtered before being used by a web application.
Attackers can use these flaws to attack backend components through a web application.
Common types of attack:
forced browsing
command insertion cross site scripting buffer overflows
format string attacks
SQL injection cookie poisoning hidden field manipulation.
Unvalidated Input
May manipulate any part of HTTP Request:
URL, query string, headers, cookies, form fields.
Client-side validation is NOT sufficient.
Unvalidated Input
Countermeasure - Parameters should be validated against a “positive” specification that defines:
Data type (string, integer, real, etc…). Allowed character set.
Minimum and maximum length.
Whether null is allowed.
Whether the parameter is required or not. Whether duplicates are allowed.
Numeric range.
Specific legal values (enumeration). Specific patterns (regular expressions).
Application Firewalls.
2. Broken Access Control
Restrictions on what authenticated users are
allowed to do are not properly enforced.
Attackers can exploit these flaws to:
Access other users’ accounts.
View sensitive files.
Use unauthorized functions.
Broken Access Control
Commonly Found Broken Access Control Issues
Insecure Id’s – Using predictable ID, index, to access confidential data.
Forced Browsing Past Access Control Checks – Deep linking of administrative pages, skipping the authentication pages.
Path Traversal – The use of relative path (e.g.,
“../../target_dir/target_file”) as part of a request for information.
File Permissions.
Client Side Caching – Confidential Information are cache by the local browser.
Broken Access Control
Broken Access Control:Allowing user to access parts of the application without the appropriate privilege.
Viewing authorized content.
Authorization loopholes.
External facing administrative interfaces.
Countermeasures:
Develop well-defined access control requirements / policy.
Well defined role based and granular access control. Extensive testing.
3. Broken Authentication &
Session Management
Account credentials and session tokens are not
properly protected.
Attackers that can compromise passwords, keys,
session cookies, or other tokens can:
Defeat authentication restrictions.
Broken Authentication
Countermeasures:
Password Strength – enforced.
Password Change Controls – single mech. old/new.
Password Storage – hashed / encrypted.
Protecting Credentials in Transit – SSL. Session ID Protection – SSL / strong session ID.
Account Lists (Account Enumeration) – prevent access.
Browser Caching – turn off, insofar as possible.
Trust Relationships – avoid implicit trust. Protecting certificates & authentication keys.
4. Cross-Site Scripting (XSS) Flaws
Web application can be used as a mechanism to
transport an attack to an end user’s browser.
Successful attack can:
Disclose end user’s session token.
Attack local machine.
Spoof content to fool the user.
Cross-Site Scripting
Cross Site Scripting:Usually a result of Unvalidated Input.
Using legitimate functions of an application to send malicious scripts to another user.
Used to steal session cookies. Phishing attacks.
Two categories – Reflected and Stored
Reflected – The malicious scripts is either embedded in the requests or retrieved from another location.
Stored – The malicious scripts is stored in the database or file in the application.
Cross-Site Scripting
Countermeasures:
Rigorous positive validation:
Headers. Cookies. Query Strings. Form/hidden fields.
Encoding user-supplied output:
<, >, (, ), #, & to character entities.
5. Buffer Overflows
Web application components in some languages that do
not properly validate input can crash.
In some cases, can take control of process.
Components include:
CGI libraries.
Drivers.
Web application server components.
Buffer Overflow
Buffer Overflow often a result of:Input Validation. Format String issues.
Countermeasure:
6. Injection Flaws
Web applications pass parameters when they
access external systems or the local OS.
If attacker can embed malicious commands in
these parameters, external system may execute
those commands:
on behalf of the web application.
Injection Flaws
Injection Flaws:Executing malicious code using system or database commands.
Often found in scripting languages (Perl, PHP, Python, TCL, etc).
SQL Injection .
Command Injection.
Countermeasures:
Input validation.
Avoid using shell or system command in the application.
Use prepared statements or stored procedures for SQL queries.
7. Improper Error Handling
Error conditions that occur during normal operation (e.g.,
catch) are not handled properly.
If an attacker can cause errors to occur that the web
application does not handle, they can:
Gain detailed system information.
Deny service.
Cause security mechanisms to fail.
Crash the server.
Improper Error Handling
Improper Error Handling:
Unnecessary disclosure of detailed internal error messages such as
stack traces, database dumps, and error.
Information such as:
Database type and version. Directory structure and file location. Server Version.
Database query.
Countermeasures:
Use generic error messages.
Use centralized logging instead of displaying the error back to the user.
8. Insecure Storage
Web applications frequently use cryptographic
functions to protect information and credentials.
These functions and the code to integrate them
have proven difficult to code properly, frequently
resulting in weak protection.
Insecure Storage
Insecure Storage encompasses several general categories of problems dealing with the storage of critical data, such as:
Failure to encrypt critical data.
Insecure storage of keys, certificates, and passwords.
Improper storage of secrets in memory.
Poor sources of randomness.
Poor choice of algorithm.
Attempting to invent a new encryption algorithm. Use of Encoding instead of encryption.
Countermeasures:
Minimize use of encryption.
Only keep information that is absolutely necessary.
9. Denial of Service
Attackers can consume
web application resources
to a point where other legitimate users can no
longer access or use the application.
Attackers can also:
Lock users out of their accounts.
Cause entire application to fail.
Application Denial of Service
Application Denial of Service resulting from theexhaustion of:
Bandwidth. database connections. disk storage. CPU.
Memory.
threads.
Countermeasures:
Limit resources allocated to users.
Avoid expensive resources for un-authenticated users. Check error handling scheme for effect on overall application.
10. Insecure Configuration
Management
Strong server configuration standard is
critical to secure web applications
Servers have many configuration options that
impact security and are not secure out of the
box
Insecure Configuration
Management
Insecure Configuration Management:
Unpatched security flaws in the server software.
Server software flaws or misconfigurations that permit directory listing and directory traversal attacks.
Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages.
Improper file and directory permissions.
Unnecessary services enabled, including content management and remote administration.
Default accounts with their default passwords.
Administrative or debugging functions that are enabled or accessible.
Overly informative error messages (more details in the error handling section).
Misconfigured SSL certificates and encryption settings.
Use of self-signed certificates to achieve authentication and man-in-the-middle protection.
Use of default certificates.
Improper authentication with external systems.
Insecure Configuration
Management
Countermeasures
Start w/ guidelines from vendor / security organizations.
Harden guidelines for:
Explicit configuration of all security mechanisms.
Turning off unused services.
Setting up role-based access control.
Logging / Alerts.
Regular Configuration Maintenance: Latest vulnerabilities.
Latest security patches.
Updating guidelines.
Vulnerability Scanning.
Internal checksum for server configuration vs. guidelines.
Web Application Security
Assessment
Assessing the web server / application server / database server:
Using automated scanner to uncover common vulnerabilities.
Assessing the application:
Using combination of automated scanner and manual interrogation
(80/20 Rule):
20% of the time doing automated scan. 80% of the time manually assessing the application.
Code Review:
Automated source code / binary code scans.
K.A Far, Pillar Technologies
Web Service Security Positions
1.
Web services are really only useful internally, so security
is not a concern.
2.
Web services cannot be secured, and pose a significant
threat to the security of an otherwise robust enterprise.
3.
Web services can be secured using SSL and password
authentication, just like e-commerce sites on the web.
4.
SSL is not sufficient to secure web services, but I do not
have a basis for figuring out just what level of security I
need or what options I have.
Security Issues
Authentication:ensures that we know and approve access for the identity of a party
in a given security domain.
Authorization:
ensures that an authorized entity has access to a controlled subset of
all available secured resources.
Confidentiality:
ensures that only authorized parties can understand a secured
message.
Integrity:
ensures that a message arrives at its destination unaltered from the point it left its sender.
Non-repudiation:
ensures that a sender cannot deny that he/she sent a given message; binds a transaction to a non-refutable identity.
K.A. Faw, Pillar Technologies
Impact on Web Services
Questions arise because of the plaintext concerns
over a simple WS architecture:
how to perform authentication/authorization?
how to guarantee integrity?
how to enforce confidentiality and non-repudiation?
K.A. Faw, Pillar Technologies
A Starting Point For Authentication
HTTP BASIC-AUTH
user name and password are encoded in the HTTP
stream as Base64 encoded plaintext
stored in an HTTP header
Authorization: Basic U2thdGVib2FyZdhcmVo…
in this mode, simple Base64 decoding reveals the
credentials
there is no encryption involved
K.A. Faw, Pillar Technologies
Moving beyond BASIC-AUTH
While BASIC-AUTH is pervasive, it is not secure
The next step is to secure the BASIC-AUTH
transmission using HTTPS
HTTP is secured using the Secured Sockets Layer (SSL) SSL encrypts the messages passed back and forth in the HTTP
conversation, including the BASIC-AUTH header however, we mentioned earlier that SSL was not sufficient to
secure web services
let’s talk about what is missing…
K.A. Faw, Pillar Technologies
Why SSL is sufficient in
e-commerce applications?
1. Transactions are generally conducted within the web application context at the e-commerce site
• there are no intermediaries or multi-party transactions.
2. SSL conversations are conducted point-to-point.
3. As long as the consumer can remit payment, user credentials are
“good enough” to authenticate and authorize their transaction • meanwhile, e-commerce sites cannot generally do anything to gain
non-repudiation with their customers.
4. Individual transactions are relatively small and will not “break the bank,” when compared with total throughput.
K.A. Faw, Pillar Technologies
On the Other Hand…
An individual web service transaction can
involve literally millions of dollars of
potential risk exposure, versus a shopping
experience at amazon.com.
Remember that web services are
systems
transacting with
systems
an open communication channel could be the
conduit for a large volume of transacting data.
K.A. Faw, Pillar Technologies
What about client certificates?
The basic mechanism for authentication breaks down when we start asking a system to supply a user name and password anyway
have you ever seen a user name and password coded into system algorithms???
have you ever abused a user name and password that you learned from application code???
client certificates are one analogous, but more secure, means for
authentication
a certificate is a token that contains credentials for asynchronous encryption that remain confidential to its owner
K.A. Faw, Pillar Technologies
Benefit of client certificates
client certificates allow us to create a secured
SSL channel that guarantees non-repudiation
…so if we secure BASIC-AUTH over
HTTPS using client certificates, is that
enough???
K.A. Faw, Pillar Technologies
Essential issue of SSL
SSL encrypts the conversation between a
single client and server, including
authentication credentials
however, there is no guarantee of non-repudiation
without a client certificate
more importantly, you lose confidentiality and
non-repudiation in the presence of ANY
intermediaries or multi-party transactions
K.A. Faw, Pillar Technologies
beneath the transport layer
Since we cannot do much to secure the transport
layer when it involves a single link in an arbitrary
chain, what is left?
we have to secure the message itself.
that requires us to take a look into SOAP and a few
security standards for web services.
To add security features to the XML
communications, we can intercept the process of
marshaling and unmarshaling the request and
response
K.A. Faw, Pillar Technologies
Intercepting the SOAP request and
response
Client ServiceWeb
request response h a n d l e r h a n d l e r h a n d l e r h a n d l e r
K.A. Faw, Pillar Technologies
Anatomy of a SOAP message
To add security to the content inthe SOAP body, we will be altering the received message:
for the receiver to get back to the original message, we must add processing instructions.
those processing instructions are added to the SOAP header.
K.A. Faw, Pillar Technologies
Relevant security specifications
XML Signature for signing all or part of an
XML document
provides integrity and non-repudiation, regardless of intermediaries
XML Encryption
for encrypting portions of an XML document
provides confidentiality, regardless of intermediaries
by adding these to the authentication capabilities of BASIC-AUTH and SSL, the security picture is more complete
there are other ways to
authenticate as well
authorization is all that is left
often that requires additional effort on your part…
we will get back to this
K.A. Faw, Pillar Technologies
Fundamentals of signatures
A signature is a special form of digest computed on a relevant block of data:
a hash code is computed on the data block using a well-known algorithm: the sender computes the initial hash and adds it to the transmission.
the receiver computes the hash on the data and checks that both hash codes match.
this ensures the digest and the data block have integrity (they are unaltered from sender to receiver).
to prevent hacking, the digest is hashed a second time and then encrypted:
the hashed and encrypted digest is called a signature.
private-key encryption provides non-repudiation.
K.A. Faw, Pillar Technologies
Role of encryption
To this point we have discussed authentication,
authorization, integrity and non-repudiation
the role of encryption is to provide confidentiality it is the process of converting plaintext into ciphertext we will go into the mechanics more in the second part
for now, consider that using XML Encryption, we can selectively encrypt any portion of the SOAP body
K.A. Faw, Pillar Technologies
Securing web service entry points
In addition to the security concerns addressed so far,
there should be consideration for securing the entry
points to web services
UDDI registries
ebXML registries
web application interfaces used for developing and testing
In most cases we have seen to date, WSDL
interfaces are published and directly accessible from
unsecured points in the network.
K.A. Faw, Pillar Technologies
Securing UDDI/ebXML registries
UDDI v3 provides additional support for digitally
signing several request elements
businessEntity, businessService, bindingTemplate, tModel, publisherAssertion, etc…
this allows consumers who look up web services to be
identified with non-repudiation
Moreover, authorization is implemented such that
K.A. Faw, Pillar Technologies
Additional tactics for securing registries
Digitally-signed WSDL
XML Encryption of private request/response
elements (recall that registries are also web services)
Reducing authorization to the registry to very short
timed intervals to reduce sniffing and replay attacks
Use SAML (described next) to make assertions
about the authorization of a party
K.A. Faw, Pillar Technologies
Security Assertions Markup Language
(SAML)
Provides queries and
assertions in XML
authentication
authorization (decisions)
attributes of known security parties
Open source implementations
www.sourceid.org
www.openSAML.org
etc.
Commercial implementations SunONE Identity Server Netegrity JSAML Toolkit
Baltimore SelectAccess
Systinet WASP Card
K.A. Faw, Pillar Technologies
WS-Security
Specification defining how they apply to SOA
Submitted to OASIS in 2002 for development as a
standard
WS-Security defines headers for subject
authentication, as well as specifications for signing
and encrypting that info
there are also many related specifications that are in various states of acceptance
