Arquivo da tag: Banco de Dados

Knex.js

Knex.js is a “batteries included” SQL query builder for PostgresMSSQLMySQLMariaDBSQLite3Oracle, and Amazon Redshift designed to be flexible, portable, and fun to use. It features both traditional node style callbacks as well as a promiseinterface for cleaner async flow control, a stream interface, full featured query and schema builders, transaction support (with savepoints), connection pooling and standardized responses between different query clients and dialects.

https://knexjs.org

Vulnerabilidades e Ataques – Injection

Em um artigo anterior, falamos um pouco sobre Segurança no Software – Vulnerabilidades e Ataques.
Nesse artigo iremos dar algumas dicas de como testar seu Software usando Injection.
Nos exemplos abaixo verificar possíveis vulnerabilidades na autenticação doSoftware.

Na tela de autenticação do Software:

Teste 1
     

Primeiramente, o invasor tenta inserir um nome utilizando aspas. Isso serve só para verificar se o formulário possui alguma função, java script ou alguma linguagem que bloqueie o uso de um caractere como a apóstrofo (‘) ou aspas simples. Conforme mostra a Figura 1. Caso não seja feito esse tipo de tratamento, ocorrerá um erro da instrução SQL (incorrect Sintax). Diante desse resultado, o invasor já sabe que existem possibilidades de invasão do referido site.


O invasor tentará então aplicar códigos SQL, e, através dos erros gerados, tentará realizar a invasão.

Teste 2

Visto que o desenvolvedor não tratou a apóstrofo, o invasor segue com a sua invasão e tenta quebrar a SQL no momento em que o parâmetro é passado. Para interromper essa instrução SQL e inserir outro código, primeiramente devemos interromper o parâmetro  exatamente no momento em que ele é passado, considerando que a instrução SQL receberá o login e a senha através da caixa de texto apresentada para o usuário – conforme mostra a Figura 1. Nesse momento é que o invasor digitará um simples código: ‘ or 1=1 –.

Esse é o tipo de invasão mais comum. Nela, o apóstrofo serve para interromper o código anterior e iniciar o novo comando.

Teste 3

O exemplo acima busca os campos nm_usuario, nm_senha, nm_permissao referente a tabela usuário, quando o nm_usuário seja igual a vazio ou quando o número 1 for igual a 1. Nesse caso, a ultima condição sempre dará como verdadeira. Os últimos dois hifens servem para desconsiderar o final da String SQL.

Também é possível buscar por um usuário chamado admin, pois na maioria das bases de dados é cadastrado um usuário com esse nome, por padrão. Dessa forma, o invasor tentará invadir com o nome admin e a senha como ‘ or 1=1 como mostra a Figura 3. Se houver realmente um usuário com esse nome, ele conseguirá burlar o sistema.

  ________________________________________

O Injection também pode ser utilizado em outros campos do Software para provocar alguns erros.

Esses erros não deverão apresentar elementos como queries ou erros que possam identificar elementos estruturais.

As mensagens de erro devem ser mascaradas de forma apresentar informações sucintas para o usuário.

Em uma caixa de texto do Software:

Teste 4
          <script>alert(‘XSS’);</script>          
Pressionar a opção de submit dSoftware

Teste 5

?msg=<script>alert(‘bip’)</script>
Pressionar a opção de submit do Software

Teste 6

<img src=JaVaScRiPt:alert(‘XSS’)>
Pressionar a opção de submit do Software

Teste 7

<img”””><script>alert(“XSS”)</script>”>  
Pressionar a opção de submit do Software

Alguns exemplos de erro

Outros tipos de teste que podemos fazer nos campos do Software são:

Teste 8

Em um campo de texto digitar Tes’te
Pressionar a opção de submit do Software

O Software substitui o apóstrofe(‘) pelo duplo apóstrofe (”) ou exclui o apóstrofe (‘)

Risco Mitigado: A presença de um caractere de apóstrofe (‘) no conteúdo de uma variável concatenada no SQL é usada para delimitar strings de texto.
Se não for tratado o apóstrofe vai ocorrer um erro de SQL (incorrect Sintax)
Teste 9
          Em um campo qualquer digitar caracteres especiais
          Pressionar a opção de submit do Software
Caso o Software permita a digitação de caracteres especiais, o Plano de Testes deverá indicar que este campo permitirá a digitação de Aspas ou apostrofe bem como palavras reservadas de programação.
Não perca o próximo artigo.

http://bugs-busters.blogspot.com.br/2014/05/seguranca-no-software-vulnerabilidades.html

Ruby on Rails Connect to Multiple Databases and Migrations

Ruby on Rails connect to Multiple Databases and using ActiveRecord with multiple databases, it’s really simple take it easy. Let’s run through this.

Rake Tasks
Well, I want to handle migrations for two databases, so I need two separate Rake tasks to handle that:

desc "Migrate the database through scripts in db/migrate directory."

namespace :db do
  task :migrate do
    Rake::Task["db:migrate_db1"].invoke
    Rake::Task["db:migrate_db2"].invoke
  end

  task :migrate_db1 do
    ActiveRecord::Base.establish_connection DB1_CONF
    ActiveRecord::Migrator.migrate("db/migrate/db1/")
  end

  task :migrate_db2 do
    ActiveRecord::Base.establish_connection DB2_CONF
    ActiveRecord::Migrator.migrate("db/migrate/db2/")
  end
end

My first task is db:migrate that delegates out to db:migrate_db1 & db:migrate_db2.

Each of those establish a connection to the database and then runs the migrations from their own separate folders. This allows you to store migrations in separate folders so you can easily manage them.

The migrations are exactly the same as normal.

Database Connections
In order to get those migrations to work, I need to configure the database connections. I’m going to define everything in the database.yml just like normal, but with a different naming convention:

database.yml
defaults: &defaults
  username: root
  password: 1234567
  adapter: mysql2
  encoding: utf8
  collation: utf8_unicode_ci

db1:
  development:
    database: db1_development
    host: localhost
    <<: *defaults

  test:
    database: db1_test
    host: localhost
    <<: *defaults

  staging:
    database: db1_staging
    host: localhost
    <<: *defaults

  production:
    database: db1_production
    host: localhost
    <<: *defaults

db2:
  development:
    database: db2_development
    host: localhost
    <<: *defaults

  test:
    database: db2_test
    host: localhost
    <<: *defaults

  staging:
    database: db2_staging
    host: localhost
    <<: *defaults

  production:
    database: db2_production
    host: localhost
    <<: *defaults

I configure two separate databases db1 & db2.

Then I need to configure the app to load these now. I open application.rb or environment file(s):

application.rb
ENV['ENV'] ||= 'development'

db_conf = YAML::load(File.open(File.join(APP_PATH,'config','database.yml')))

DB1_CONF = db_conf["db1"][ENV['ENV']]
DB2_CONF = db_conf["db2"][ENV['ENV']]

Take a look at what’s going on:
– I set the database configuration to use. You can just use Rails.env here instead of ENV[‘ENV’].
– I load up the database.yml config and parse it with YAML.
– I grab the configuration from the file for each db and the correct environment that I’m running in.

Connecting Models
When I’m working with multiple databases, I like to explicitly setup the connections inside the models themselves instead of inheriting from ActiveRecord::Base and using subclasses.

user.rb
class User < ActiveRecord::Base
  establish_connection DB1_CONF
end
product.rb
class Product < ActiveRecord::Base
  establish_connection DB2_CONF
end

Well, All you really need to do is load the configurations, establish the database connections, and setup the migrations to load from a specific directory for each database.

Don’t know how to build task…

Try renaming the file to sample_data.rake.

I was able to get your example working (replacing the internals of the task with a p statement) by putting your code in a file called testomatic.rake in lib/tasks.

http://geekhmer.github.io/blog/2015/02/07/ruby-on-rails-connect-to-multiple-databases-and-migrations

JMeter – Building a Database Test Plan

In this section, you will learn how to create a basic Test Plan to test a database server. You will create fifty users that send 2 SQL requests to the database server. Also, you will tell the users to run their tests 100 times. So, the total number of requests is (50 users) x (2 requests) x (repeat 100 times) = 10’000 JDBC requests. To construct the Test Plan, you will use the following elements: Thread Group, JDBC Request, Summary Report.

http://jmeter.apache.org/usermanual/build-db-test-plan.html