R’da Paket Kurulumu

R’a eklenti olarak paket kurmak oldukça kolay. Öncelikle ihtiyacınız olan analizlere ilişkin paketleri R’ın sitesinden bulabilirsiniz:

http://cran.ncc.metu.edu.tr/web/packages/available_packages_by_date.html

Örneğin benim analiz etmek istediğim interrater reliability olduğu için Kappa analizine yönelik paketlere ihtiyaç duyuyorum. Sayfada CTRL+F ile arama yaparak kendinize uygun paketler bulabilirsiniz. Toplamda 5 tane paket kuracağım ve kuracağım paketler şunlar:

  1. ICC: Facilitating Estimation of the Intraclass Correlation Coefficient
  2. KappaV: Calculates “vectorial Kappa”, an index of congruence between patchy mosaics
  3. irr: Various Coefficients of Interrater Reliability and Agreement
  4. raters: A Modification of Fleiss’ Kappa in Case of Nominal and Ordinal Variables
  5. KappaGUI: GUI for Cohen’s and Fleiss’ Kappa

Paket isimleri şu şekilde: ICC, KappaV, irr, raters ve KappaGUI.

Gelelim kuruluma. R konsolunu açtıktan sonra “install.packages” komutu ile paketleri kurabiliyorsunuz. “install.packages” fonksiyonu R’da ki diğer fonksiyonlar gibi vektör kabul ediyor. Yani bu fonksiyon içerisinde birden çok paketin kurulmasını söyleyebilirsiniz. Örneğin tek bir paket:

veya birden çok paket:

Bazı paketler uzun zamandır güncellenmediği için kullandığınız R sürümüyle uyumlu olmayabilirler. Bu durumda şöyle bir hata mesajı alırsınız:

Ek olarak R paketlerinin dependency olarak tanımlanmış paketleri de otomatik kurduğunu belirteyim. Yani örneğin irr’yi kullanabilmek için ICC’ye ihtiyaç duyuluyorsa R bunu da otomatik olarak kuracaktır.

Her şey yolunda gittiyse paketleriniz kurulmuş olmalı. R’da kurmuş olduğunuz paketleri kullanabilmek için ise mevcut oturumda o paketleri çağırmanız da gerekmekte. Bunu da şu şekilde yapabilirsiniz:

Herhangi bir paketi mevcut oturumdan kaldırmak içini ise detach komutu kullanılıyor:

Kolaylıklar.

İki Veri Arasında ki Benzerliğin Hesaplanması – Ruby

Bir RoR projesinde, iki farklı veritabanında bulunan ad-soyad ve kimlik numarası verilerinin birbirlerine ne kadar benzediğinin hesaplanması ve farklı veri setlerinin birbiriyle aynı olma olasılığının tespiti gibi bir ihtiyacım olmuştu.

Örneğin aşağıda ki iki veri birbirine ne kadar benziyor, bu kişiler gerçekten aynı kişiler olabilir mi hesaplamam gerekiyordu:

Bu hesaplamayı yapabilmek için Elasticsearch ve Ruby’nin marifetleri yeterli oldu. Elasticsearch’ün Ruby için sağladığı “records.each_with_hit” metodu ile herhangi iki veri birbirlerine ne kadar benziyor (yakınsıyor) kontrol edebilir ve benzerlik oranını 0-2 aralığında matematiksel olarak alabilirsiniz.

Örnek betik şu şekilde:

Betikte bulunan “1.2” değeri, tamamen benim istediğim yakınlık derecesini ifade etmekte. Daha yüksek yakınlığa sahip verileri tespit etmek için bu değeri arttırabilir, daha geniş bir aralık almak için azaltabilirsiniz. Betik çalıştıktan sonra şöyle bir çıktı veriyor:

Kolaylıklar.

Ruby on Rails ve Güvenlik – CSRF ve API Talepleri

CSRF ve Authenticity Token

Rails’te herhangi bir formdan POST request yaparken authenticity_token parametresi de gönderilmekte. Bu parametre CSRF saldırılarına karşı Rails’in kullandığı default savunma mekanizmasının bileşenlerinden biri. Aşağıda POST işlemi yapan örnek bir form bulunuyor, hidden field olarak authenticity_token gönderildiğini görebilirsiniz.

İşin hikayesi ise şöyle; Rails POST request’leri için user’ın session bilgisini temel alarak rastgele bir hash oluşturup bunu form içerisinde hidden field olarak ekliyor ve request esnasında gönderiyor. Oluşturulan token form submit edildiğinde diğer parametrelerle birlikte gönderiliyor ve web uygulaması tarafından işleniyor.

POST request’in akabinde web sunucumuz gönderilen token ile mevcut kullanıcının session bilgisini kıyaslıyor ve eşleşmeyen bir durum bulunduğunda bunu saldırı olarak kabul ediyor. Eğer Rails’in default davranışını değiştirmediyseniz request’in hataya düşmesi gerekiyor. Aşağıda POST işlemi yapan bir form görebilirsiniz. Henüz token’ı kurcalamadık.

POST işlemi yapan form
POST işlemi yapan form

Session’a erişme şansı olmayan bir saldırgan gibi davranıp token’ı değiştirelim ve neler olduğunu inceleyelim (Token’ın son 2 karakteri olan “==” karakterlerini “??” olarak değiştirdim):

Parametreleri değiştirilmiş form.
Parametreleri değiştirilmiş form.

Sonuç olarak beklendiği üzere uygulama exception’a düştü ve hata verdi =>

Rails CSRF protection

Uygulamanın bu davranışı göstermesini sağlayan ise application_controller’da bulunan “protect_from_forgery” metodu.

Kod aslında yaptığı işi açıkça söylüyor. Diğer bir yandan da API’lar için null_session kullanmamızı öneriyor. Eğer uygulamanız içerisinde bir API barındıracaksanız protect_from_forgery with: :exception yaptığınız request’leri hataya düşürecek çünkü Rails authenticity_token’ı sizin request’iniz içerisine eklemeyecek. Deneyelim:

Konfigürasyon: 

API Request:

API Request Sonucu:

with: :exception ile uygulamayı hataya düşürme davranışına alternatif olarak reset_session ve null_session seçeneklerini de kullanabilirsiniz:

  • :reset_session – Oturumu sıfırlar.
  • :null_session – Request esnasında yeni boş bir oturum sağlar ancak mevcut oturumu sıfırlamaz.

Detaylardan bir kaç ilginç nokta:

  1. Yeni bir Rails uygulaması oluşturduğunuzda “protect_from_forgery” metodu with: :exception ayarlı olarak geliyor.
  2. Rails 4’te => “protect_from_forgery” metodunu tek başına çağırdığınızda default davranışı “reset_session” şeklinde. Bknz: source.
  3. Rails 3’te => “protect_from_forgery” metodunu tek başına çağırdığınızda default davranışı “null_session” şeklinde.

GET mi – POST mu?

protect_from_forgery metodu sadece POST metodu için çalışmakta. Diğer bir değişle GET request’i için CSRF koruması uygulanmıyor. Bu durum Rails kaynak kodu içerisinde şu şekilde ifade ediliyor:

“GET requests are not protected since they don’t have side effects like writing to the database and don’t leak sensitive information.”

Sonuç olarak GET request’lerine hassas bilgiler döndürmemek ve GET request’lerinden gelen parametreleri veritabanına yazmamak önem taşıyor. Eğer hatalı bir kurgu izlemiş ve veritabanı ile olan ilişkilerinizi GET üzerine kurmuşsanız öncelikle bu hatalı kurguyu değiştirmeniz gerekiyor.

API Uygulamaları ve CSRF

Web uygulamanız içerisinde API sunma niyetindeyseniz yukarıda bahsettiğim şekilde “with: :exception” API request’lerinizi hataya düşürecektir çünkü browser üzerinden yapılmayan request’lerde Rails authenticity_token parametresini request’e ekleyemeyecek. O halde hem API  request’lerini hemde normal uygulama request’lerini aynı anda nasıl güvende tutacağız?

1) JSON request’lerini protect_from_forgery’den muaf tut

Request =>

Response =>

Response içerisinde CSRF token’ın doğrulanamadığını söylüyor ancak :exception çalıştırmadığımız için ve default davranış “reset_session” olduğu için API requestimiz başarıyla çalışıyor ve yanıtını alıyor. Bu uyarı sadece loglanıyor ve client’ın sorgularına engel olmuyor. Diğer bir yandan form üzerinden POST yaparken token’ı değiştirirsek uygulama session’ı sıfırlayacak ve POST request’imiz iptal edilecek.

Request =>

Response =>

Bir önce ki POST request ile bu POST request arasında fark, ilk request’in /query yoluna yapılmış, ikinci request’in ise /query.json yoluna yapılmış olması. Dolayısıyla request bir JSON isteği olduğu için uygulama artık loglara token doğrulanamadı hatasıda basmıyor.

Dezavantaj => Eğer  :exception kullanmak istiyorsanız /query yolunun default davranışından fedakarlık etmeniz gerekecek çünkü uygulama bu yolda hata verecek.

Sonuç olarak vardığım en sağlıklı sonuç şu konfigürasyon ile oldu =>

2) API controller’larını protect_from_forgery’den muaf tut

Eğer API request’lerini idare eden controller sadece JSON sunuyorsa callback’lerden faydalanabiliriz. Eğer controller hem bir template render ediyor hemde JSON sunuyorsa CSRF korumasını kapatmak güvenlik zaafiyetine yol açacaktır.

Sadece index action’unu muaf tut =>

Controller’ı muaf tut =>

Diğer detaylar için metodun kaynak kodunu okuyabilirsiniz:

https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/request_forgery_protection.rb

 

Ruby on Rails ve Güvenlik – Routes

Rails uygulamalarında route’ların güvenliğini sağlarken Devise gibi authentication GEM’lerinin sağladığı helper’lardan ve lambda metodundan yararlanabilirsiniz. Örneğin sadece super_admin rolüne sahip kullanıcılara açık olmasını istediğiniz route’ları şu şekilde tanımlayabilirsiniz:

Artık admin/resque, admin/ip_lists ve admin/token_users yolları sadece super_admin’ler için erişilebilir olacak.

Model tarafında ise is_super_admin? metodunu şu şekilde tanımlı:

Selamlar.

ElasticSearch HQ Eklentisi Kurulumu

Elasticsearch plugin’lerinin kurulacağı yer:

HQ eklentisini kurmak için:

Eklentiye ulaşmak ve çalıştırmak için: