developers

Views:
 
Category: Education
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Slide1: 

Security For Web Application Developers By Jim Truitt Information Security Engineer Security for Web ApplicationsDevelopers

Introduction or Why are you bothering me?: 

Introduction or Why are you bothering me? Web sites are moving away from static HTML to dynamic interactive web applications. It is the dynamic, interactive web application that is making the Internet the universal medium. Web applications bring a new level of risk to web sites. Security of these web applications is paramount to the security of the site. Applications designed without security in mind may result in loss of data integrity, availability, confidentiality and loss of privacy.

What? Me worry?: 

What? Me worry?

You could be at risk if…..: 

You could be at risk if….. You are a large corporation that attracts many users to your corporate web site. You have just released a statement boasting about the security of your site. You are competing and releasing a new product in the marketplace. You are a financial institution. You are a government organization. You are a provider of many knowledge-related or data services. You are an e-commerce site.

An interesting statistic: 

An interesting statistic Just last year, the numbers of web site defacements rose over 900% (source: ). This can result in embarrassment and unnecessary media exposure. Some publicly traded companies have seen their stock value go down as a result of a breach in the security of their web site.

Programming today isn’t like it used to be: 

Programming today isn’t like it used to be 1. It’s a new computing environment 2. It’s a new coding environment 3. Security Testing is different 4. Documentation 5. Error Messages 6. Your new worst enemies 7. Some Security related exposures 8. Some rules for securing web apps.

It’s a new computing & coding environment or When I was Young...: 

It’s a new computing & coding environment or When I was Young... When I was young we used “proprietary” assemblers, compilers, linkers & catalogers. When I was young we generated “binary executables” that were “hosted” on the main processor Today you use “commercially available” “standards based” development environments Today your code is “distributed”, “mobile”, “interpreted” and “viewable”

The Beat goes on …..: 

The Beat goes on ….. The Media dedicated to shared The Architecture closed to open centralized to distributed The Connectivity direct terminal server LAN/WAN global Internet End User Capability dumb terminal to intelligent desktop

Security Testing is Different: 

Security Testing is Different Static testing involves manually inspecting the source code and automatically testing for dangerous constructs. Dynamic testing involves executing the web application to detect for anomalous behavior on unexpected inputs. Functional testing != Security Testing In Functional testing you make sure the code does what it is designed to do. Security testing requires that the code not only perform its’ functional tasks, but that it also be resistant to “non-conforming” usage.

Security Testing Some passing thoughts: 

Security Testing Some passing thoughts Malicious individuals can exploit web-based applications to gain access to privileged information. The tools used to execute the exploits are easily available and require minimal knowledge. The very same tools and methods may be used to test the robustness of web applications. Exhaustive testing of web applications will require building test scenarios to identify vulnerabilities.

Documentation: 

Documentation All good coders know it’s good to “comment” their code liberally to enhance understandability when reviewed by persons other than coder. When I was young, comments did not show up in the “compiled” “binary” executable to which the end user had access. Now, your comments in html, javascript, Java applets, etc. are easily viewable by all end users (and potential hackers). Today you code using commercially available devlopment environments and tools . Potential hackers have access to the same set of “helpful tools” as the developer. Today you code to “standards”. These published standards provide potential hackers detailed insight into the internal workings of the programs you develop.

Error Messages: 

Error Messages Error messages used to be directed to the “Operator’s Console” or the “System Logger” or to some other controlled device. Now your error messages pop up on the end user’s PC screen (good guy or bad guy). The end user can use whatever information is supplied in whatever manner they choose. Hackers will deliberately feed an application bogus input just to see what information the application will cough up.

Your New Worst Enemies: 

Your New Worst Enemies Right mouse button Save link as View source Cut & paste

Some Security Related Exposures: 

Some Security Related Exposures Cookie Poisoning Form Manipulation Bypassing Intermediate Forms in a Multiple-Form Set Embedded Queries to a Relational Database Session Timeouts Directory Listing

Cookie Poisoning: 

Cookie Poisoning Sometimes cookies are used to store information such as user host name, password, account ID, session ID and other user profile information. A hacker may obtain the cookie by various means, including physical access or network sniffing, as well as guessing the cookie's contents. If a user is able to capture the cookies by sniffing on the network, or by any other means, he may be able to gain unauthorized access to personal information, including credit card number, passwords, user ID and mailing address.

Cookie Poisoning Security measures you can take : 

Cookie Poisoning Security measures you can take Use non-persistent cookies instead of persistent cookies. If you must use persistent cookies, then specify a short duration for the cookie's life. The longer the time until cookie expiration, the larger the risk. Avoid application features that use persistent cookies to store privacy-related information. Use the secure tag, so that the cookie is sent only if a secure channel (https) is being used. Encrypt the information in the cookies.

Form Manipulation: 

Form Manipulation Form manipulation involves saving a web site's form and editing it off-line. While client-side validation is a good technique from a performance point of view, it is not the preferred solution from a security point of view. Poorly designed web applications may contain hidden fields that contain user IDs, account IDs or other key fields that define user sessions. All this information can be manipulated off-line to gain access to another user's session. Form manipulation is a simple technique and requires only a knowledge of HTML.

Form Manipulation Security measures you can take: 

Form Manipulation Security measures you can take Perform referrer checks on the server side. This will ensure that a given form was reached from the page that contains the hyperlink providing access to the form. Do not rely on the form field-length checks or JavaScript to ensure form input integrity. Perform form input-length checks on the server as well. Process and validate the form input field values entered by the user for range, expected input (e.g., numeric vs. alphabetic), strange characters and any other associations specific to the user. Do not store critical user information in hidden fields in the form.

Bypassing Intermediate Forms in a Multiple-Form Set: 

Bypassing Intermediate Forms in a Multiple-Form Set Sometimes forms are filled out in sequence. Malicious users may be able to bypass the intermediate forms by typing out the entire form name in the browser URL field instead of using the navigation controls provided by the web site pages. This may result in unexpected application behavior, accessing a defunct application, incomplete database records or buffer overflow.

Bypassing Intermediate Forms in a Multiple-Form Set Security measures you can take: 

Bypassing Intermediate Forms in a Multiple-Form Set Security measures you can take Ensure the user progresses to the next form only after all the required information requested in the preceding forms is provided. Furthermore, ensure the user visited all preceding forms. Perform referrer checks on the server side. This will ensure a given form was reached from the page that contains the hyperlink providing access to the form.

Embedded Queries to a Relational Database: 

Embedded Queries to a Relational Database Many times, form fields are used to send input provided by users to the back end web site for further processing. A malicious user may input field entries in such a way that the returned result provides additional information about other users as well. In addition, the embedded queries may run other SQL commands, such as pipe commands, which may result in disclosure of confidential information.

Embedded Queries to a Relational Database Security measures you can take: 

Embedded Queries to a Relational Database Security measures you can take The web application must carefully examine the input fields used to create the database queries for illegal characters, for example an asterisk (*). Validate and ensure that input fields contain only the relevant user-related information. Ensure proper permissions exist on the database objects accessed by the web application.

Session Timeouts Part 1: 

Session Timeouts Part 1 Many site administrators feel secure simply because the site is using SSL for all its sessions. SSL provides for data transmission security between the web client and the web server. Once an SSL session is established, all information exchanged between the web server and the web client is encrypted.

Session Timeouts Part 2: 

Session Timeouts Part 2 The session timeout specifies the “no activity” duration beyond which the user will have to re-authenticate himself to the web site. The session timeout is usually based on the type of application. Serious financial institutions may specify a very short session timeout period. Regular applications, such as web-based e-mail, may use longer timeout periods. A malicious user may be able to hijack another user's session if session timeouts are too long.

Session Timeouts Security measures you can take: 

Session Timeouts Security measures you can take Your security measure is to evaluate carefully the session timeouts for your application. If you are using multiple application servers, then ensure the session timeouts for the multiple applications are consistent with the timeouts determined for the entire web site.

Directory Listing: 

Directory Listing Most servers are configured with automatic directory listing. This means any directory that does not contain any of the default files (for example, index.htm or default.htm) served by the server will display the contents of the directory. Malicious users may be able to browse the directories and download key files. Files that contain source code may be examined to identify trap doors to gain access into the web server or applications.

Directory Listing Security measures you can take: 

Directory Listing Security measures you can take Configure the web server to specify all default files that may be used and to disable directory browsing. Establish proper procedures when adding the web-application files. Ensure that unnecessary files are periodically removed.

Rules for Securing Web Apps: 

Rules for Securing Web Apps Don’t expose the directory tree. Make session tokens difficult to forge. Assume anything downloaded to the client can be modified. Use server-side commenting when possible. Without client-side certificates, SSL is subject to a man in the middle attack. If putting something on a Web page, understand how it works. Be security aware.

Summary: 

Summary Dynamic content on web sites will continue to enhance the business functionality of web sites; it is supported by a growing number of e-commerce sites. Also, these web applications are increasingly connected to databases that were previously accessible only through internally built custom applications. Malicious individuals can exploit these web-based applications to gain access to privileged information. Quite often just a text editor and a browser are sufficient tools to hack. The tools used to execute the exploits are easily available and require minimal knowledge.

Summary (continued): 

Summary (continued) Testing of web applications will require building test scenarios to identify vulnerabilities. Proper web-application designs, web-server configuration, secure programming practices and good housekeeping are necessary for the security of any web site and a site's privileged resources. Due to the custom nature of web applications, they pose a challenge to the security of web sites. In the future, web applications are expected to be more secure, as certified components used to build applications gain support.

Credits: 

Credits “Assessing the Secuirty of Your Web Applications”, by Nalneesh Gaur “A Half-Dozen Rules for Securing Your Web Applications”, by Charles Forsythe “Securing Active Web Content”, by Ron Morritz “The World Wide Web Security FAQ”, from http://www.w3.org/Security/Faq

Questions and Answers: 

Questions and Answers

authorStream Live Help