Published on

Security Programing Techniques

Authors
  • avatar
    Name
    Predrag TASEVSKI
    Twitter

INTRODUCTION

The main goal of this post is to introduce the reader with the security programing techniques into deferent program languages and operating system security models. The post is introducing four following topics:

  1. Session storage’s in Ruby on Rail
  2. Parameterized statements into Java with JDBC, C# with ASP.NET, PHP5, php-mysqli, Perl, Python and Hibernate Query Language (HQL)
  3. Unix permission model, Unix ACL and Windows 7 security model
  4. Finding all the security vulnerabilities in bash script

Each topic will be divided into own section, where at the end of each topic we stated the reference and additional reading material. The source code, scrips and the additional task were given by the lecture. However this will help the readers and people interesting into programing for further work and involvement with the above topics.

  1. Session storage’s in Ruby on Rail

Session in Rails is a hash-like structure which allows you to store data across requests. Sessions can hold any kind of data object (with some limitations) because they store data using Data Marshalling.Session in rails it is not a hash. Session creates new instant of session in every time new user visit the site. Recommendation is to not store large objects in a session and critical data should not be stored in session.Rails way of

implementing session is:

  1. session_id is a 32 hex character MD5 hash based upon time, random number and constant string. It is stored in cookie at client browser. Rails provides transparent support for session_id.
  2. Session storage discussed below.

Ruby on Rails provides with many session storage option:

  1. PStore – it implements a file based persistence mechanism based on a Hash. User code can store hierarchies of Ruby objects (values) into the data store file by name (keys). An object hierarchy may be just a single object. User code may later read values back from the data store or even update data, as needed. The files that are stored are usually located in the tmp/sessions folder for the Rails app. The main downside of using the PStore is that you will have to do some session-pruning periodically because performance decreases as the number of sessions stored increases.
  2. ActiveRecordStore – keeps the session id and hash in a database table and saves and retrieves the hash on every request.
  3. CookieStore – it saves the session hash directly in a cookie on the client-side. The server retrieves the session hash from the cookie and eliminates the need for a session id. Cookie-based sessions are just faster to retrieve and process than hitting the file-system on every request, were it was previously. Cookies are generally limited to 4K in size. While not an issue for most (proper) usage of the session, this could be a legitimate limit for some scenarios. If your application abuses the session, you’ll need to decide on a different session store that are available. The cookie has a SHA512 fingerprint attached and is hashed with a secret stored up on the server and there are, however, derivatives of CookieStore which encrypt the session hash, so the client cannot see it.
  4. DRbStore – it store uses distributed Ruby to store a user’s session data. The performance is great, but it requires a bit more setup than the other stores.
  5. FileStore – This store keeps the fragments on the hard disk instead of in memory. It works well if you have a lot of file storage and have outgrown the MemoryStore.
  6. MemoryStore – keeps your session data in server memory. It keeps the fragments in your application’s memory, which can potentially take up a lot of memory on your server. It is used by default, but it is hard to manage and scale if your application becomes popular.

Note: Ruby on Rail CookieStore is available only in edge rails. PStore is the default option for stable release, whereas its CookieStore as default for edge rails.

Reference

Ruby On Rails Security Guide, link

Sessions and cookies in Ruby on Rails, [link](https://www.quarkruby.com/2007/10/21/sessions-and-cookies-in-ruby-on-rails\#sstorage](https://www.quarkruby.com/2007/10/21/%20sessions-and-cookies-in-ruby-on-rails#sstorage)

What’s New in Edge Rails: Cookie Based Sessions are the New Default, [link] (https://ryandaigle.com/articles/2007/2/21/what-s-new-in-edge-rails-cookie-based-sessions)

  1. Parameterized statements into Java with JDBC, C# with ASP.NET, PHP5, php-mysqli, Perl, Python and Hibernate Query Language (HQL)

For this task we will take a look at the parameterized statement API-s and we will find out and document how much does each of them protect against the following possible misuses of SQL statements:

  • String injection (quotes, double quotes)
  • SQL statement injection (expression syntax etc)
  • Out of range integers
  • Blind SQL injection

Java with JDBC

PreparedStatement prep =conn.prepareStatement("SELECT * FROMUSERSWHERE USERNAME=? AND PASSWORD=?");prep.setString(1, username);prep.setString(2, password);prep.executeQuery();

There are no possibilities of string injection because of the filtering the statements. It enables users’ input to be initially filtered instead of directly embedding it in the SQL statements. In this example is that the each parameter is a scalar, not a table, where the user input is then assigned (bound) to a parameter. It is a good idea if the character range is limited. Another thing that can be done to avoid SQL injection is to convert numeric values to integers before parsing them into the SQL statement. Or using ISNUMERIC to verify that they are integers.

C# with ASP.NET

using (SqlCommand myCommand =new SqlCommand("SELECT * FROM USERSWHEREUSERNAME=@user ANDPASSWORD=HASHBYTES(’SHA1’, @pwd)",myConnection)){myCommand.Parameters.AddWithValue("@user",user);myCommand.Parameters.AddWithValue("@pwd",pass);myConnection.Open();SqlDataReader myReader =myCommand.ExecuteReader();...}

The placeholder – @user and the hashbyte value of password @pws – has become part if the hardcoded SQL. At runtime, the value provided by the querystring is passed to the database along with the hardcoded SQL, and the database will check the Username and password field as it attempts to bind the parameter value to it. This ensures a level of strong typing. If the parameter value is not the right type for the database field (a string, or numeric that’s out of range for the field type), the database will be unable to convert it to the right type and will reject it. If the target field datatype is a string (char, nvarchar etc), the parameter value will be “stringified” automatically, which includes escaping single quotes. It will not form part of the SQL statement to be executed.

PHP5

$db = new PDO(’pgsql:dbname=database’);$stmt = $db-prepare("SELECT priv FROM testUsers WHERE username=:username AND password=:password");$stmt-bindParam(’:username’, $user);$stmt-bindParam(’:password’, $pass);$stmt-execute();

In this example to protect against SQL injection, it is used an input not directly to be embedded in SQL statements. Instead, it is used an parameterized statements (preferred), or user input must be carefully escaped or filtered. This example shows and parameterized example/statement in php v. 5 and PDO database to protect from SQL injections and blind SQL injections.

PHP-MySQLi

$db = new mysqli("host", "user", "pass","database");$stmt = $db - prepare("SELECT priv FROM testUsers WHERE username=? AND password=?");$stmt -  bind_param("ss", $user, $pass);$stmt - execute();

Same as above but this time it is used the vendor-specific methods; for instance, using the mysqli extension for MySQL 4.1 and create parameterized statements to protect from the SQL injection.

Perl

use DBI;my $db = DBI-connect(’DBI:mysql:mydatabase:host’, ’login’, ’password’);$statment = $db->prepare("UPDATE players SET name = ?, score = ?, active = ? WHERE jerseyNum = ?");$rows_affected = $statment->execute("Smith, Steve", 42, ’true’, 99);

Automatically “sanitize” input to parameterized SQL statements to avoid the catastrophic database attacks.

Python


import sqlite3db = sqlite3.connect(’:memory:’)db.execute(’update players set name=:name, score=:score,active=:active where jerseyNum=:num’, {’num’: 100, ’name’: ’John Doe’, ’active’: False, ’score’: -1})

It is parameterized statement with an example of named placeholders. Which insure to avoid the SQL injections and database attacks.

Hibernate Query Language (HQL)

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");safeHQLQuery.setParameter("productid", userSuppliedParameter);

Unsafe example: Query unsafeHQLQuery = session.createQuery(“from Inventory where productID=’”+userSuppliedParameter+”‘”); The example from left it’s used prepared statement approach because all the SQL code stays within the application. This makes your application relatively database independent. However, other options allow you to store all the SQL code in the database itself, which has both security and non-security advantages and the approach is called Stored Procedure

  1. Unix permission model, Unix ACL and Windows 7 security model

In this topic we will describe two security set-ups that can not be expressed with traditional Unix permission model, UNIX ACL and Windows 7 security model.

Unix permission model

  • Giving an different permission to different users in the same group
  • Read and write permission/access to all groups, which gives and access to the ‘private files’, and you can gain access through a root account by an unwanted user, which brings and complete breach of the system

Unix ACL- enabled permission model

  • If the user has permission over the file, he can read/write and delete it, which brings that it is not possible to give ‘some’ permission to the user.
  • ACL’s are not very portable and are very hard to maintain. For instance good example is transferring of files with ACL’s between different of Unix systems is an exercise for brave person, even if the both file systems support them. Which brings a difficulty to maintain for existing files for instance backup, restore, copying, etc.

Windows 7 security model

  • As a standard user you can perform an action that requires administrator privileges by the UAC(User Access Control), which is controlled by the Admin Approval Mode. It can be turn off and on. Every time when you need to gain an access of the administration privileges it will be prompt a dialog box to gain and provide the password for an access. Therefore in the medium settings with any malware could turn it off.
  • And the settings of the UAC are in medium mode not off, still brings an opportunity to being turn off by the malware.

  1. Finding all the security vulnerabilities in bash script

In this topic we will find all the possible vulnerabilities into the following bash script:

+--------------------------------------+--------------------------------------+ | | | | | | | 1 2 3 4 5 6 7 8 910111213141516 | #!/bin/sh# remove files with nam | | 17181920212223 | e pattern matching regexpif [ x$1 = | | | x ]; then# if [[ x$1 = x ]]echo -n " | | | Please enter directory name: "read d | | | irelsedir=1fiif[x1fiif [ x2 = x ]; then# | | | if [[ x2=x]]echo−n"Pleaseente∣∣∣rpattern:"readpatternelsepattern=∣∣∣2 = x ]]echo -n "Please ente | | | r pattern: "read patternelsepattern= | | | 2fifind dir &g | | | t; /tmp/listing# can use &am | | | p;amp;amp;gt;&gt | | | ; or print the output first beforecm | | | d='rm `grep 'pattern' /tmp/listing` | | | ' #+the command is executeecho "Runn | | | ing command cmd"evalcmd"eval cmd //it conv | | | erts string in commandrm /tmp/listin | | | gexit 0 | | | | | | ``` | | | | | | | | | | +--------------------------------------+--------------------------------------+

We should avoid temporary file, instead we should use pipes [2]. We should avoid eval [2].

Using the double brackets, instead of single one [[... ]] it is comment on the script above [1]. $REPLY can be used to read the previous value of the dir and pattern variable [1]. We can use instead of find, while read contracture (loop) [1]. Find – can be set with a cycle, for or while to check the validation of the file and the directory/path, also comment on the script or using “$pattern” /tmp/listing [1]. No sensitization of the input, the user can put any value and therefore, execute any command to create another command. As we can see above the script it looks like that it is security vulnerable. If we want to implement the security in the script we should implement the above changes into the script.

Reference

[1] Mendel Cooper, 30 April 2011. Advanced Bash-Scripting Guide; An in-depth exploration of the art of shell scripting. Retrieved. link

[2] Lecture 8 slides Scripting, Meelis Roos.

Discuss on Twitter • View on GitHub