September 24, 2013

Case equality operator === in ruby

To enable developers to write neat, compact code, Many classes take advantage of implementing their own versions of '==='. The '===’ operator is known as the case equality operator. The '===’ operator is used when testing cases in case statements.
def test_object number 
  case number
    when Fixnum
      case number 
        when 1  
          puts "It's One"
        when 2..10  
          puts "Between two and ten"
          puts "-- #{number} -- is not between one and ten"
    when String 
      puts "You passed a string"
    else "I have no idea what to do with -- #{number} --"
for each 'when' statement the '===' operator is called on the when argument (1,2..10,String) and the case argument (number) is used for the comparison. For line 5 the comparison done shall be '1 === number'. For most classes ‘===’ is just an alias to ‘==’ however some classes redefine ‘===’ to allow for better functionality in case statements. In Ruby a Proc is a block of executable code, an anonymous function which can be passed around as if it were data. Like ‘===’, a Proc can map a number of arguments to either a true or false value.
is_weekday = lambda {|day_of_week, time| time.wday == day_of_week}.curry  
    sunday    = is_weekday[0]  
    monday    = is_weekday[1]  
    tuesday   = is_weekday[2]  
    wednesday = is_weekday[3]  
    thursday  = is_weekday[4]  
    friday    = is_weekday[5]  
    saturday  = is_weekday[6]  
    when sunday   
      puts "Day of rest"  
    when monday, tuesday, wednesday, thursday, friday  
      puts "Work"  
    when saturday  
      puts "Happy"  
Simple Factorial lambda function in Ruby
factorial = lambda do |n|
  n <= 1 ? 1 : (n * - 1))
end 3

July 24, 2013

SQL Injection in rails

How to avoid SQL Injection in rails

How to avoid SQL Injection in rails

SQL injection is a problem that every web developer needs to be aware of when accepting parameters that will during the life of the request be converted into SQL statements. Rails historically has done what it can to mitigate this risk for the developer by providing vehicles for sanitizing parameter inputs at the points when they are being converted for use inside of a SQL statement, however with Rails 3 there are numerous ways to execute a SQL statement against the database and some of these methods are safer than others.
Consider two cases where valid Rails code is vulnerable to SQL injection:

user inputed parameters

params[:query] = "'username'; DROP TABLE EMPLOYEE;"

CASE 1 - find_by_sql

User.find_by_sql("SELECT * FROM users WHERE (name = '#{params[:query]}'")

(Not Good)

generated SQL

SELECT users.* FROM users WHERE (email = ''); DROP TABLE EMPLOYEE; ')
The example above shows how find_by_sql can allow parameters submitted by a user to be directly entered into a SQL statement and how an attacker might use the vulnerability to wreak havoc. These types of find_by_sql statements used to be more commonly used in earlier versions of Rails (1.0 - 2.0) and it was through these statements that the Rails community realized that SQL injection was a problem that needed addressing. Here's another example prominent in the early Rails days:
User.find :first, :conditions => "(name = '#{params[:query]}')" ##(BAD BAD BAD) produces this SQL statement:

generated SQL

SELECT users.* FROM users WHERE (email = ''); DROP TABLE EMPLOYEE;')
The above example shows a common Rails idiom for performing an ActiveRecord query, as with the previous find_by_sql example the find query here is piping the param in directly and generating the exact same tainted SQL.
Fortunately, Rails core decided to make it easier to just do the right thing and provided ways to pass in parameters by using built-in filters that handle special SQL characters, which will escape ’ , " , NULL character and line breaks. Instead of passing in the parameter directly as a raw string, you can pass in an array to sanitize the tainted strings using the built-in filters:
User.find_by_sql(["SELECT * FROM users WHERE (name = ?)", params])
User.find :first, :conditions => ["(name = '?')", params]

generated SQL

The distinction in the filtered SQL statement is the escaped single quote right after the t in Robert which prevents the name parameter from terminating and allowing the DROP TABLE EMPLOYEE from being executed since it remains a part of the string parameter. Additionally, Rails also included these built-in filters automatically when AR queries were called from find_by_something or a conditions hash:


generated SQL

SELECT * FROM users WHERE = 'username\'); DROP TABLE EMPLOYEE; ' (RETURNS NIL) User.find :first, :conditions => {:name => params}


Rails 3 introduced AREL, which is another way to perform ActiveRecord queries and with it came as well, another way to make the exact same SQL injection mistakes that are already listed above. However having gotten accustomed to looking for SQL injection vulnerabilities in the AR query formats above you might be lulled into thinking that the new and improved ActiveRecord query methods would just magically handle the tainted strings for you and you'd be dead wrong:
User.where("name = '#{params}'") (BAD) SELECT users.* FROM users WHERE (name = 'username'); DROP TABLE EMPLOYEE; ##') ##(THIS STATEMENT WILL DROP TABLE EMPLOYEE)
The nice thing is that the same fix can also be applied:
User.where(["name = ?", params]) SELECT users.* FROM users WHERE (name = ''username\'); DROP TABLE EMPLOYEE;

July 9, 2013

Rails way web caching and caching

A web cache is a mechanism for the temporary storage (caching) of web documents, such as HTML pages and images, to reduce bandwidth usage, server load, and perceived lag. So that future requests for that data can be served faster.

Rails provides three types of caching techniques by default without the use of any third party plugins.
1) Page caching
2) Action caching
3) Fragment caching

1) Page Caching:

Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. Apache or nginx), without ever having to go through the Rails stack at all. Obviously, this is super-fast. Unfortunately, it can't be applied to every situation (such as pages that need authentication) and since the webserver is literally just serving a file from the filesystem.
To enable page caching, you need to use the caches_page method.

class ProductsController < ActionController

  caches_page :index

  def index
    @products = Products.all

  def create
    expire_page :action => :index


By default, the page cache directory is set to Rails.public_path (which is usually set to the public folder) and this can be configured by changing the configuration setting config.action_controller.page_cache_directory.

In order to expire this page when a new product is added we could extend our example controller like above.

2) Action Caching:

One of the issues with Page Caching is that you cannot use it for pages that require to restrict access somehow(such as pages that need authentication). This is where Action Caching comes in. Action Caching works like Page Caching except for the fact that the incoming web request does go from the webserver to the Rails stack and Action Pack so that before filters can be run on it before the cache is served. This allows authentication and other restriction to be run while still serving the result of the output from a cached copy.
class ProductsController < ActionController

  before_filter :authenticate
  caches_action :index

  def index
    @products = Product.all

  def create
    expire_action :action => :index


You can also use :if (or :unless) to pass a Proc that specifies when the action should be cached. Also, you can use :layout => false to cache without layout so that dynamic information in the layout such as logged in user info or the number of items in the cart can be left uncached.

Action Caching and Page Caching runs in an after filter. Thus, invalid requests won't generate spurious cache entries as long as you halt them. Typically, a redirection in some before filter that checks request preconditions does the job.

3) Fragment Caching:

Sometimes you only want to cache a section of a page instead of the entire page. Fragment caching is the answer of this.
Fragment Caching allows a fragment of view logic to be wrapped in a cache block and served out of the cache store when the next request comes in.

As an example, if you wanted to show all the orders placed on your website in real time and didn't want to cache that part of the page, but did want to cache the part of the page which lists all products available, you could use this piece of code:

<% Order.find_recent.each do |o| %>
  <%= %> bought <%= %>
<% end %>

<% cache do %>
  All available products:
  <% Product.all.each do |p| %>
    <%= link_to, product_url(p) %>
  <% end %>
<% end %>
The cache block in our example will bind to the action that called it and is written out to the same place as the Action Cache, which means that if you want to cache multiple fragments per action, you should provide an action_suffix to the cache call:
<% cache(:action => 'recent', :action_suffix => 'all_products') do %>
          All available products:

June 4, 2013

install_name_tool reporting malformed object in Mountain Lion


Every-time I try to use install_name_tool on my machine it reports the following

install_name_tool: object: xxxxx.x.x.x.dylib malformed object (unknown load command 4) 

I observed that this error could be generated when building the binary.
Whenever I try to change something using install_name_tool. It produces the same result about malformed object (unknown load command 4)

Currently I have XCode Version 4.6.2 running on Mac OSX 10.8.3

I found the solution for this.

After wasting lots of time trying different things finally I found that install_name_tool is not updated when XCode is updated. You need to install the Command Line Tool from XCode > Preferences.

install_name_tool on Mac OS X Mountain Lion.

This resolved the same error for me.

April 18, 2013

Install ssh on ubuntu

Install ssh with
sudo apt-get install ssh

Say yes to everything it asks you to install.
Note, you will now have an /etc/ssh/ directory under which you will find a ssh_config and sshd_config file you may have to uncomment a few lines in later.
You then want to run this command:
ssh-keygen -t rsa 

On safer side, it is a good idea to throw a pass phrase in there. For little security.  Make sure it is difficult to guess and NOT the same as your log in password.
Note, it should default to generating 2048 bit encryption which is always better than 1024. You will get a public and private file i.e.
id_rsa and
You put the id_rsa which is the private key, in the ~/.ssh directory. You put the public key one up on the server you are remotely connecting too. You can cut and paste it in usually. Make sure you do not introduce any unwanted white space in it. DO NOT put the private key one up on the server you are connecting too.

You may need to restart the service/deamon with
sudo service ssh restart 

This would be necessary if you changed anything in one of the config files. Make sure your permissions are right on the ~./.ssh directory and the files in there.
drwx------ # for .ssh directory
-rw------- # id_rsa for the private key 

Now type from your Ubuntu prompt:

April 15, 2013

Pymongo - TypeError: index 'password' cannot be applied to Cursor instances

In the 10Gen course I am taking of Mongo-db, we are using python to access mongo via pymongo.

I received this "TypeError : index … cannot be applied to Cursor instances" error while attempting to do the following:

user = self.users.find({'_id' : username})
salt = user['password'].split(',')[1]

where the "self" variable gave a connection to the mongo db, "users" was a collection on that db, and "username" was a string variable passed into a function containing this code. Initially I didn’t realize that the find() method will always return a full cursor rather than a single document, even if the where clause specifies the primary key field, _id. I’m currently working with iplbeats right now, which when retrieving a "cursor" (users) will always return a single "document" (sObect) if the primary key is supplied in the where clause.

The solution was clear: replace the find() method with the find_one() method to return a document rather than a cursor.


April 9, 2013

How to avoid SQL Injection in Rails

SQL injection is any situation in which a user can manipulate a database query in an unintended manner. Consequences of SQL injection vulnerabilities range from data leaks, to authentication bypass, to root access on a database server.

Most Rails applications interact with a database through ActiveRecord, the default and convenient Object Relational Mapping (ORM) layer which comes with Rails. Generally, use of ORMs is safer. ORM can provide abstraction and safety and allow developers to avoid manually building SQL queries. ORM can incorporate best practices and prevent loosely handling of user input.

sqlquery = "SELECT * FROM users WHERE name = '#{name}' AND password = '#{password'} LIMIT 1"
results = DB.execute(sqlquery)

Safer, simpler code like
User.where(:name => name, :password => :password).first

Rails framework will protect them as long as they avoid the "obviously dangerous" methods, like find_by_sql.
ActiveRecord does provide parametrization of queries or some methods. But for some methods it does not provide parametrization of sql queries, these methods are not intended to be used with user input.
Here is an example of using exists?
User.exists? params[:user_id]
However, there is no guarantee params[:user_id] is a string.
Hacker could send a request with ?user_id[]=some_hack_string, which Rails will turn into an array ['some_hack_string']. Now the argument is an array, the first element of which is not escaped.

To avoid this problem, we need to convert the user input to the expected type:
User.exists? :id => params[:user_id]
User.exists? params[:user_id].to_i
This should be the approach for all uses of user input.

Share It