OWASP - User contributions [en]

What are web applications?

2008-04-18T12:32:31Z

Cstromblad: /* Scripting */

[[Guide Table of Contents]]

__TOC__

In the early days of the web, web sites consisted of static pages, which severely limited interaction with the user. In the early 1990’s, this limitation was removed when web servers were modified to allow communication with server-side custom scripts. No longer were applications just static brochure-ware, edited only by those who knew the arcane mysteries of HTML; with this single change, normal users could interact with the application for the first time.

[[Image:What are web applications.JPG]]

This is a huge and fundamental step towards the web as we know it today. Without interactivity, there would be no e-commerce (such as Amazon), no web e-mail (Hotmail or Gmail), no Internet Banking, no blogs, no online share trading, and no web forums or communities like Orkut or Friendster. The static Internet would have been vastly different to today.

The trend towards increased interactivity has continued apace, with the advent of “Web 2.0”, a term that encompasses many existing technologies, but heavily features highly interactive, user centric, web-aware applications.

==Technologies ==

Initially, it was quite difficult to write sophisticated applications. The first generation web applications were primitive, usually little more than form submissions and search applications. Even these basic applications took quite a great deal of skill to craft.

Over time, the arcane knowledge required to write applications has been reduced. Today, it is relatively easy to write sophisticated applications with modern platforms and simpler languages, like PHP or VB.NET.

However, this push to make applications as easy to write as possible has a downside – many entry-level programmers are completely unaware of the security implications of their code. This is discussed further in the “Security Principles” chapter.

Let’s look at the various generations of web application technology.

==First generation – CGI ==

Common Gateway Interface (CGI) reigned supreme from approximately 1993 through to the late 1990’s when scripting languages took over in a big way.

CGI works by encapsulating user supplied data in environment variables. These are inherited by the custom written scripts or programs, usually developed in Perl or C. The custom programs process the supplied user data, and send fully formed HTML to the “standard out” (stdout), which is captured by the web server and passed back to the user.

Examples of complex CGI include Hotmail, which was essentially Perl scripts running on top of FreeBSD boxes and Slashdot, again a large Perl script running under Linux

As few sites today write new CGI applications, the techniques to secure CGI applications are not discussed within the Guide. However, many of the techniques discussed can be used with few or no changes.

==Filters ==

Filters can be used to control access to a web site, implement a different web application framework (such as Perl, PHP, or ASP), or to provide a security check.
Because filters live within the execution context of the web server itself, they can be high performance. Typical examples of a filter interface include Apache web server modules, SunONE’s NSAPI, and Microsoft’s ISAPI. Filters can be written in C/C++ in order to integrate with the web/app server at a low-level. However, more recently, filters are being implemented in higher level languages, using interfaces like the J2EE filter API.

==Scripting ==

CGI’s lack of session management and authorization controls hampered the development of commercially useful web applications.

Web developers turned to scripting languages, such as PHP and Ruby to solve these problems. Scripting languages run script code within the web server without being compiled.


Unlike low-level languages where programmers have to deal with memory allocation themselves, scripting languages deal with memory management internally. This allows them to avoid, most of the time, problems such as buffer overflows and resource leaks and thus, programmers who use them can at least avoid some security related issues common in low-level languages. However, they are not without flaws:

* Most scripting languages aren’t strongly typed and do not promote good programming practices

* Scripting languages are generally optimized for particular types of data manipulation. Often programmers choose the wrong language to solve the right problem, resulting in poor application performance that is sometimes blamed on the language itself.

* It’s difficult (but not impossible) to write multi-tier large scale applications in scripting languages, because often the presentation, application and data tiers reside on the same machine, thus limiting scalability and security

* Most scripting languages do not natively support remote method or web service calls, which makes it difficult to communicate with application servers and external web services.

Despite their disadvantages, many large and useful applications have been written with scripting languages, such as eGroupWare (egroupware.org), which is written in PHP. Too, many older Internet banking sites are written in ASP.

Scripting frameworks include ASP, Perl, ColdFusion, and PHP. However, many of these would be considered interpreted hybrids now, particularly later versions of PHP and ColdFusion, which pre-tokenize and optimize scripts.

==Web application frameworks – J2EE and ASP.NET ==

As scripting languages reached the boundaries of performance and scalability, many larger vendors jumped on Sun’s J2EE web development platform. There are many J2EE implementations, including Tomcat from the Apache Foundation, JBoss and Glassfish.


J2EE:

* Uses the Java language to produce applications which run nearly as quickly as C++ based ones, and that do not easily suffer from buffer overflows and memory leaks

* Allowed large distributed applications to run acceptably for the first time

* Possesses good session and authorization controls

* Enabled relatively transparent multi-tier applications via various remote component invocation mechanisms, and

* Is strongly typed to prevent many common security and programming issues before the program even runs

J2EE’s downside is that it has a steep learning curve which makes it difficult for web designers and entry-level programmers to use it to write applications. While certain graphical development tools make it somewhat easier to program with J2EE, a scripting language like PHP is still much easier to use.

When Microsoft updated their ASP technology to ASP.NET. which mimics the J2EE framework in many ways, they offered several improvements on the development process. For example, .NET:

* Makes it easy for entry level programmers and web designers to whip up smaller applications

* Allows large distributed applications

* Offers good session and authorization controls

* Allows programmers to use their favorite language, which is compiled to native code for excellent performance (near C++ speeds), along with buffer overflow and resource garbage collection

* Permits transparent communication with remote and external components

* Is strongly typed to prevent many common security and programming issues before the program even runs

The choice of J2EE or ASP.NET frameworks is largely dependent upon platform. There is little reason to choose one over the other from a security perspective.

Applications targeting J2EE theoretically can run with few (if any) changes between any of the major vendors and on many platforms from Linux, to AIX, MacOS X, or Windows. (While in practice, some tweaking is required, complete re-writes are not required. )

# ''ASP.NET is primarily available for Microsoft Windows. The Mono project (http://www.go-mono.com/) can run ASP.NET applications on many platforms including Solaris, Netware, and Linux. ''

==Small to medium scale applications ==

Most applications are either small or medium scale. The usual architecture is a simple linear procedural script. This is the most common form of coding for ASP, ColdFusion and PHP scripts, but rarer (but not impossible) for ASP.NET and J2EE applications.

The reason for this architecture is that it is easy to write, and few skills are required to maintain the code. For smaller applications, any perceived performance benefit from moving to a more scalable architecture will never be recovered in the development time for those applications. For example, if it takes an additional three weeks of developer time to re-factor the scripts into an MVC approach, the three weeks will never be recovered (or noticed by end users) from the improvements in scalability.

It is typical to find many security issues in such applications, including dynamic database queries constructed from insufficiently validated data input, poor error handling and weak authorization controls.

This Guide provides advice throughout to help improve the security of these applications.

==Large scale applications ==

Larger applications need a different architecture to that of a simple survey or feedback form. As applications get larger, it becomes ever more difficult to implement and maintain features and to keep scalability high. Using scalable application architectures becomes a necessity rather than a luxury when an application needs more than about three database tables or presents more than approximately 20 - 50 functions to a user.

Scalable application architecture is often divided into tiers, and if design patterns are used, often broken down into re-usable chunks using specific guidelines to enforce modularity, interface requirements and object re-use. Breaking the application into tiers allows the application to be distributed to various servers, thus improving the scalability of the application at the expense of complexity.

One of the most common web application architectures is model-view-controller (MVC).  The main concept of MVC is to keep the code that displays content (the view) completely separate from the data and business logic (the model). The controller exists to handle user input. Lets use an order form as an example to solidify these terms. The html of the form, its layout and anything you *see* that is not data should be generated by the view. You type your information into the form and click the "purchase" button. Behind the scenes, the controller receives this information and passes it on to the model. The model either accepts the data or rejects it (if, for example, you forgot to enter your name). If the data is accepted, the controller forwards you to the next view (perhaps a view that says you successfully ordered the product). If the data is rejected, the controller may forward you back to the order form view with error messages on the page saying you need to enter your name.

MVC is typical of most Apache Foundation Jakarta Struts applications, and the code-behind ASP.NET can be considered a partial implementation of this approach. For PHP, the WACT project (http://wact.sourceforge.net) aims to implement the MVC paradigm in a PHP friendly fashion.

==View ==

The front-end rendering code, often called the presentation tier, should aim to produce the HTML output for the user with little to no application logic.

As many applications will be internationalized (i.e. contain no localized strings or culture information in the presentation layer), they must use calls into the model (application logic) to obtain the data required to render useful information to the user in their preferred language and culture, script direction, and units.

All user input is directed back to controllers in the application logic.

==Controller ==

The controller (or application logic) takes input from the users and gates it through various workflows that call on the application’s model objects to retrieve, process, or store the data.

Well written controllers centrally server-side validate input data against common security issues before passing the data to the model for processing, and ensure that output is safe or in a ready form for safe output by the view code.

As the application is likely to be internationalized and accessible, the data needs to be in the local language and culture. For example, dates cannot only be in different orders, but an entirely different calendar could be in use. Applications need to be flexible about presenting and storing data. Simply displaying “7/4/2005” is ambiguous to anyone outside a few countries.

==Model ==

Models encapsulate functionality, such as “Account” or “User”. A good model should be transparent to the caller, and provide a method to deal with high-level business processes rather than a thin shim to the data store. For example, a good model will allow pseudo code such as this to exist in the controller:

<pre>
oAccount->TransferFunds(fromAcct, ToAcct, Amount)
</pre>

rather than writing it such as this:

<pre>
if ( oAccount->isMyAcct(fromAcct) &&
amount < oAccount->getMaxTransferLimit() &&
oAccount->getBalance(fromAcct) > amount &&
oAccount->ToAccountExists(ToAcct) )
then
if oAccount->withdraw(fromAcct, Amount) == OK
then oAccount->deposit(ToAcct, Amount)
end if
end if
</pre>

The idea is to encapsulate the actual dirty work into the model code, rather than exposing primitives. If the controller and model are on different machines, the performance difference will be staggering, so it is important for the model to be useful at a high level.

The model is responsible for checking data against business rules, and any residual risks unique to the data store in use. For example, if a model stores data in a flat file, the code needs to check for OS injection commands if the flat files are named by the user. If the model stores data in an interpreted language, such as SQL, then the model is responsible for preventing SQL injection. If it uses a message queue interface to a mainframe, the message queue data format (typically XML) needs to be well formed and compliant with a DTD.

The contract between the controller and the model needs to be carefully considered to ensure that data is strongly typed, with reasonable structure (syntax), and appropriate length, whilst allowing flexibility to allow for internationalization and future needs.

Calls by the model to the data store should be through the most secure method possible. Often the weakest possibility is dynamic queries, where a string is built up from unverified user input. This leads directly to SQL injection and is frowned upon. For more information, see the Interpreter Injections chapter.

The best performance and highest security is often obtained through parameterized stored procedures, followed by parameterized queries (also known as prepared statements) with strong typing of the parameters and schema. The major reason for using stored procedures is to minimize network traffic for a multi-stage transaction or to remove security sensitive information from traversing the network.

Stored procedures are not always a good idea – they tie you to a particular database vendor and many implementations are not fast for numeric computation. If you use the 80/20 rule for optimization and move the slow and high-risk transactions to stored procedures, the wins can be worthwhile from a security and performance perspective.

==Conclusion ==

Web applications can be written in many different ways, and in many different languages. Although the Guide concentrates upon three common choices for its examples (PHP, J2EE and ASP.NET), the Guide can be used with any web application technology.

[[Guide Table of Contents]]

[[Category:OWASP_Guide_Project]]

Policy Frameworks

2008-04-17T10:26:05Z

Cstromblad:

[[Guide Table of Contents]]
__TOC__

Secure applications do not just happen – they are the result of an organization deciding that they will produce secure applications. OWASP does not wish to mandate a particular approach or require an organization to pick up compliance with laws that do not affect them - every organization is different.

However, for a secure application, the following at a minimum are required:

* Organizational management which champions security

* A written information security policy properly derived from national standards

* A development methodology with adequate security checkpoints and activities

* Secure release and configuration management processes

Many of the controls within OWASP Guide 2.0 are influenced by requirements of national standards or control frameworks such as COBIT; typically controls selected out of OWASP will satisfy relevant ISO 27002(17799) and COBIT controls.

==Organizational commitment to security ==

Organizations that have security buy-in from the highest levels will generally produce and procure applications that meet basic information security principles. This is the first of many steps along the range between ad hoc “possibly secure (but probably not)” to “best practices”.

Organizations that do not have management buy-in, or simply do not care about security, are extraordinarily unlikely to produce secure applications. Each secure organization documents its “taste” for risk in their information security policy, thus making it easy to determine which risks will be accepted, mitigated, or assigned.

Insecure organizations simply don’t know where this “taste” is set, and so when projects run by the insecure organization select controls, they will either end up implementing the wrong controls or not enough controls. Rare examples have been found where every control, including a kitchen sink tealeaf strainer has been implemented, usually at huge cost.

Most organizations produce information security policies derived from ISO 27002(17799), or if in the US, from COBIT, or occasionally both or other standards. There is no hard and fast rule for how to produce information security policies, but in general:

* If you’re publicly traded in most countries, you must have an information security policy

* If you’re publicly traded in the US, you must have an information security policy which is compliant with SOX requirements, which generally means COBIT controls

* If you’re privately held, but have more than a few employees or coders, you probably need one

* Popular FOSS projects, which are not typical organizations, should also have an information security policy

It is perfectly fine to mix and match controls from COBIT and ISO 27002(17799) and most any other respected information security standard; rarely do they disagree on the details. The method of production is sometimes tricky – if you “need” certified policy, you will need to engage qualified firms to help you.

==OWASP’s Place at the Framework table ==

The following diagram demonstrates where OWASP fits in (substitute your own country and its laws, regulations and standards if it does not appear):

[[Image:Policy_frameworks.JPG]]

Organizations need to establish information security policy informed by relevant national legislation, industry regulation, merchant agreements, and subsidiary best practice guides, such as OWASP. It is impossible to draw a small diagram containing all relevant laws and regulations, so you should assume all of the relevant laws, standards, regulations, and guidelines are missing – you need to find out which affect your organization, customers (as applicable), and where the application is deployed.

IANAL: OWASP is not a qualified source of legal advice; you should seek your own legal advice.

===''COBIT''===

COBIT is a popular risk management framework structured around four domains:

* Planning and organization

* Acquisition and implementation

* Delivery and support

* Monitoring

Each of the four domains has 13 high level objectives, such as DS5 ''Ensure Systems Security. ''Each high level objective has a number of detailed objectives, such as 5.2 ''Identification, Authentication, and Access''. Objectives can be fulfilled in a variety of methods that are likely to be different for each organization.

COBIT is typically used as a SOX control framework, or as a complement to ISO 27002(17799) controls.

OWASP does not dwell on the management and business risk aspects of COBIT. If you are implementing COBIT, OWASP is an excellent start for systems development risks and to ensure that custom and off the shelf applications comply with COBIT controls, but OWASP is not a COBIT compliance magic wand.

Where a COBIT objective is achieved with an OWASP control in this book, you will see “COBIT XXy z.z” to help direct you to the relevant portion of COBIT control documentation. Such controls should be a part of all COBIT compliant applications.

For more information about COBIT, please visit http://www.isaca.org/

===''ISO 27002(17799)''===

ISO 27002(17799) is a risk-based Information Security Management framework directly derived from the AS/NZS 4444 and BS 7799 standards. It is an international standard and used heavily in most organizations, although not in the US. However, a few US organizations use ISO 27002(17799) as well, particularly if they have subsidiaries outside the US.

ISO 27002(17799) dates back to the mid-1990s, and some of the control objectives reflect this age – for example referring to administrative interfaces as “diagnostic ports”.

Organizations using ISO 27002(17799) can use OWASP for detailed guidance when selecting and implementing a wide range of ISO 17799 controls, particularly those in the Systems Development chapter, among others. Where a 27002(17799) objective is achieved with an OWASP control in this book, you will see “ISO 27002(17799) X.y.z” to help direct you to the relevant portion of ISO 27002(17799). Such controls should be a part of all ISO 27002(17799) compliant applications.

For more information about ISO 27002(17799), please visit http://www.computersecuritynow.com/ and the relevant standards bodies, such as Standards Australia (http://www.standards.com.au/), Standards New Zealand (http://www.standards.co.nz/), or British Standards International (http://www.bsi-global.com/).

Note that ISO 17799 was renamed to ISO 27002 in July 2007, to achieve numerical alignment with ISO's overall security standards set (ref: http://www.27000.org)

===''Sarbanes-Oxley''===

A primary motivator for many US organizations in adopting OWASP controls is to assist with ongoing Sarbanes-Oxley compliance. If an organization followed every control in this book, it would not automatically grant the organization SOX compliance. Therefore, The Guide is useful as a suitable control for application procurement and in-house development, as part of a wider compliance program.

However, SOX compliance is often used as a case for resource starved IT managers to implement long neglected security controls, so it is important to understand what SOX actually requires. A summary of SOX, section 404 obtained from AICPA’s web site at http://www.aicpa.org/info/sarbanes_oxley_summary.htm states:

Section 404: Management Assessment of Internal Controls

Requires each annual report of an issuer to contain an "internal control report", which shall:

* state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and

* contain an assessment, as of the end of the issuer's fiscal year, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.

This essentially states that management must establish and maintain internal ''financial control ''structures and procedures, and conduct an annual evaluation that verifies the controls are effective. As finance is no longer conducted using double entry ledger books, “SOX compliance” is often extended to mean IT.

The Guide can facilitate SOX compliance by providing effective controls for all applications, and not just for the purposes of financial reporting. It allows organizations to buy products which claim they use OWASP controls, or allows organizations to mandate to software suppliers that they must use OWASP controls to provide more secure software.

However, avoid using SOX as an excuse. SOX controls are intended to prevent another Enron, not to buy widgets that may or may not help. All controls, whether off the shelf widgets, training, code controls, or process changes, should be selected based on measurable results and ability to manage risk, and not just to “tick the boxes”.

==Development Methodology ==

High performing development shops employ a development methodology and some set of coding standards or conventions. As it turns out, the choice of development methodology is not as important as simply having one.

Ad hoc development is too unstructured to produce secure applications. Therefore, organizations who wish to produce secure code consistently need to utilize a methodology that supports that goal. Choose carefully – small teams should never consider heavy weight methodologies that identify many different roles, while large teams must choose methodologies that will scale to their needs.

Here are some key attributes to look for in selecting a development methodology:

* Strong acceptance of design, testing, and documentation processes

* Clear instances where security controls (such as threat risk analysis, peer reviews, code reviews, etc) can be slotted in

* Works well for the organization’s size and maturity

* Has the potential to reduce the current error rate and improve developer productivity

* Will scale as the organization or product line grows

==Coding Standards ==

Methodologies alone are not coding standards; each team will either need to determine what to use based upon common practice, or simply lay down the law based upon known best practices.

Inputs to consider:

* Architectural guidance (i.e., “The web tier cannot call the database directly”)

* Minimum documentation levels required

* Mandatory testing and coverage requirements

* Minimum levels of code commenting and the preferred comment style

* Proper use of exception handling

* Correct use of flow of control blocks (e.g., “All uses of conditional flow shall use explicit statement blocks”)

* Preferred variable, function, class, and table naming styles

* A preference for maintainable and readable code over clever or complex code

Indentation style and tabbing are a holy war, and from a security perspective, they simply do not matter that much. However, it should be noted that we no longer use 80x24 terminals, so vertical space usage is not as important as it once was. Indent and tabbing can be “fixed” using automated tools or simply a style within a code editor, so do not get overly fussy on this issue.

==Source Code Control ==

High performance software engineering requires the use of regular improvements to code, along with associated testing regimes. All code and test changes must be able to be versioned and capable of being reverted.

This could be done by copying folders on a file server, but it is better performed by source code revision tools, such as Subversion, CVS, SourceSafe, or ClearCase.

Why include tests with a software revision? Most simply put, because tests for later builds will not necessarily match the tests required for earlier builds. So, it is vital that a test is applied to the build for which it was intended.

==Summary ==

The use of policy frameworks does not automatically guarantee secure applications or standards compliance. However, it is very difficult to produce secure applications consistently without some structure in place to do so.

Select your policy framework carefully -- it should meet the needs of your organization today, while providing room for growth, too.

Finally, get started today! Incorporating a security-conscious development process is a crucial first step to delivering secure applications. Your policy framework and development process should leverage your local conventions, risk management goals, and applicable standards to ensure a secure and quality result.

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Requirements]]

Talk:What are web applications?

2008-04-17T07:17:27Z

Cstromblad:

(cstromblad) The '''scripting''' section should perhaps be revised? Unsubstantiated claims such as being 100 times slower, often leading to unmanageable code base etc. really doesn't add much to the discussion. I'd suggest that we either remove this part, or substantiate the claims with raw data to give these arguments some foundation to stand on.

Take the unmanageable code base. Is this really a problem to the script language? Or is this a problem in how they are used and by whom, and for what?

Talk:What are web applications?

2008-04-17T07:16:21Z

Cstromblad:

(cstromblad) The '''scripting''' section should perhaps be revised? Unsubstantiated claims such as being 100 times slower, often leading to unmanageable code base etc. really doesn't add much to the security teaching. I'd suggest that either remove this part, or substantiate these claims with raw data. Take the unmanageable code base. Is this really a problem to the script language? Or is this a problem in how they are used and by whom, and for what?

I've not made any changes because I'd like to learn what other people think about this.

Talk:What are web applications?

2008-04-17T07:15:39Z

Cstromblad: New page: The scripting section should perhaps be revised? Unsubstantiated claims such as being 100 times slower, often leading to unmanageable code base etc. really doesn't add much to the securit...

The scripting section should perhaps be revised? Unsubstantiated claims such as being 100 times slower, often leading to unmanageable code base etc. really doesn't add much to the security teaching. I'd suggest that either remove this part, or substantiate these claims with raw data. Take the unmanageable code base. Is this really a problem to the script language? Or is this a problem in how they are used and by whom, and for what?

I've not made any changes because I'd like to learn what other people think about this.