Oracle RAC and Dataguard

A lot of IT managers get confused between what a Oracle RAC does and what Dataguard does.

Oracle RAC provides us with a cluster of Oracle instances for the same database/datastore. This enables massive scalability and availability. But it does not provide protection against failure of the database or corruption of the data. e.g. natural disaster that resulted in data-loss or data-corruption.

Oracle dataguard enables creation of a standby database at a DR site and thus provides data protection.

ViewState in ASP.NET

There is so much confusion over what ViewState does and why is it required. Finally the following link helped me in understanding a lot of things:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

Snippets from the above article:
Server Controls utilize ViewState as the backing store for most, if not all their properties. That means when you declare an attribute on a server control, that value is usually ultimately stored as an entry in that control's ViewState StateBag.
ASP.NET calls TrackViewState() on the StateBag during the OnInit phase of the page/control lifecycle. This little trick ASP.NET uses to populate properties allows it to easily detect the difference between a declaratively set value and dynamically set value.
When the StateBag is asked to save and return it's state (StateBag.SaveViewState()), it only does so for the items contained within it that are marked as Dirty. That is why StateBag has the tracking feature. In order for data to be serialized, it must be marked as dirty. In order to be marked as dirty, it's value must be set after TrackViewState() is called.

When the page first begins to load during a postback (even prior to initialization), all the properties are set to their declared natural defaults. Then OnInit occurs. During the OnInit phase, ASP.NET calls TrackViewState() on all the StateBags. Then LoadViewState() is called with the deserialized data that was dirty from the previous request. The StateBag calls Add(key, value) for each of those items. Since the StateBag is tracking at this point, the value is marked dirty, so that it may be persisted once again for the next postback.

ViewState is only one way controls maintain values across postbacks. Regular good old HTML FORMS play a role, too. For example, disable viewstate on a textbox, and it will still maintain its value, because it is POSTING the value with the form. Make that TextBox invisible then do a post, and the value is lost. Thats where ViewState helps, which would allow it to maintain the value even if its invisible.

The option to set control properties in the OnPreInit event in order to avoid those values from being entered into the viewstate is a good idea to avoid storing these values in the ViewState. To avoid Datagrids from storing values in the ViewState, rebind the data to the grid on each page load.

Security Principles

Browsing thru the OWASP site, I came across the following security principles that are of interest while designing the security architecture. Every security policy has 3 objectives:
a) Confidentiality b)Integrity c)Availability

Examples of security principles:
1: Securing the weakest link (The chain is only as strong as its weakest link) - e.g. Attackers will not target the firewall, but the applications accessible through the firewall.

2: Minimize Attack Surface Area - design the system such that the potential areas for intrusion are reduced.

3. Principle of Least Privilege - only give those permissions to the user that are required.

4. Principle of Defense in Depth - e.g. Do validations at the front-end using Javascript, in the web-tier using validation logic, in the database using constraints and triggers.

5. Fail securely - If an application/program fails, then it should not leave the system in an insecure state.

6. Separation of Duties - e.g.an administrator should be able to turn the system on or off, set passwordpolicy but shouldn’t be able to log on to the storefront as a super privileged user, such as beingable to buy goods on behalf of other users.

7. Don't just rely on security by obscurity. Use security by design. Use elements of both the strategies.

The following links provide interesting material for reading:
http://www.infoworld.com/article/05/08/19/34OPsecadvise_1.html
http://en.wikipedia.org/wiki/Honeypot_%28computing%29

XSS and CSRF attacks

Of late, I have been doing a lot of study to understand 'Cross-Site Scripting' attacks and 'Cross Sitre Request forging' attacks.
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc. http://www.technicalinfo.net/papers/CSS.html
http://www.shocking.com/~rsnake/xss.html

How to prevent XSS atacks? Tips from the www.owasp.org site
1. Use proper input validation techniques
2. Encoding the output. This includes data read from files and databases.
For input validation, its better to go for a ‘positive’ security policy that specifies what is allowed rather than a ‘Negative’ or attack signature based policies as they are difficult to maintain and are likely to be incomplete.

The following link at MSDN contains some good info about preventing XSS attacks:
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
Microsoft even has a "Anti-Cross Site Scripting Library" available at:
http://msdn2.microsoft.com/en-us/library/aa973813.aspx

The OWASP site defines CSRF as follows:
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

One technique to prevent event CSRF attacks is to use the 'Token Synchronization' pattern. Sample filters for JEE and .NET are available on the OSWAP site at the following links:
http://www.owasp.org/index.php/CSRF_Guard
http://www.owasp.org/index.php/.Net_CSRF_Guard

Storing sensitive information in properties file

In JEE and .NET applications we often store data access configuration parameters such as username, password, datasource URL in properties files. But how to protect this sensitive information? The obvious answer is to encrypt the file or the 'string' properties. But then the question is - where do U store the key? If U encrypt the key, then U would require another key to decrypt this key...a classic chicken-and-egg problem.

Browsing thru OWASP site pages, I came across this page that contained some interesting ideas for this problem. Snippet from the site:

"Some environments have protected locations, such as the WebSphere configuration files, or the system registry. You can use a file in a protected location, that uses OS access control to limit access to only the application. You could put the key in the code, but that makes it difficult to change and deploy securely. You can also force the master key to be entered when the system boots up so it's only in memory, but that means you lose automatic reboot. You can even split the key and put parts in more than one of these locations."

The page also contains a sample implementation in Java for encrypting properties file.

Various types of performance testing

Came across this site (http://www.loadtest.com.au/types_of_tests.htm) that lists down the various types of testing that can be done to performance test a system. Given below are snippets from the above page.

1. Load Testing: Load Tests are end to end performance tests under anticipated production load. The primary objective of this test is to determine the response times for various time critical transactions and business processes and that they are within documented expectations (or Service Level Agreements - SLAs). The test also measures the capability of the application to function correctly under load, by measuring transaction pass/fail/error rates.
2. Stress Testing: Stress Tests determine the load under which a system fails, and how it fails. This is in contrast to Load Testing, which attempts to simulate anticipated load. It is important to know in advance if a ‘stress’ situation will result in a catastrophic system failure, or if everything just 'goes really slow'. There are various varieties of Stress Tests, including spike, stepped and gradual ramp-up tests. Catastrophic failures require restarting various infrastructure and contribute to downtime, a stress-full environment for support staff and managers, as well as possible financial losses.
3. Volume Testing: Volume Tests are often most appropriate to Messaging, Batch and Conversion processing type situations. In a Volume Test, typically the Response times are not measured. Instead, the Throughput is measured. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed. For batch processing, the type of records in the batch as well as the size of the database that the batch process interfaces with will have an impact on the number of batch records that can be processed per second.
4. Network Testing: Network sensitivity tests are tests that set up scenarios of varying types of network activity (traffic, error rates...), and then measure the impact of that traffic on various applications that are bandwidth dependant. Very 'chatty' applications can appear to be more prone to response time degradation under certain conditions than other applications that actually use more bandwidth. For example, some applications may degrade to unacceptable levels of response time when a certain pattern of network traffic uses 50% of available bandwidth, while other applications are virtually un-changed in response time even with 85% of available bandwidth consumed elsewhere.This is a particularly important test for deployment of a time critical application over a WAN.
5. Failover Testing: Failover Tests verify of redundancy mechanisms while under load. For example, such testing determines what will happen if multiple web servers are being used under peak anticipated load, and one of them dies. Does the load balancer react quickly enough? Can the other web servers handle the sudden dumping of extra load? This sort of testing allows technicians to address problems in advance, in the comfort of a testing situation, rather than in the heat of a production outage.
6. Soak Testing: Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed. It is important to identify such situations in a test environment.