[SP-pm] DBIx::Class

Tiago Peczenyj tiago.peczenyj at gmail.com
Mon Sep 16 02:41:10 PDT 2013


muitas aplicações sao vulneraveis a ataques de exaustao de recursos e
ataques "ddos".

para isso precisa-se de, entre outras coisas, de um balanceador de carga
bem configurado com maxconn, rajada, etc. monitoração e umas regras marotas
de iptables/nginx/etc. eh divertido de brincar com isso quando vc tem tempo
livre, pode ficar retornando erros aleatorios quando o cara ta forcando a
barra.


2013/9/16 Solli Honorio <shonorio at gmail.com>

>
>
> Em 16 de setembro de 2013 00:53, Eduardo Verissimo <everissimo at gmail.com>escreveu:
>
> Depende, Solli.
>>
>> Eu penso em um caso típico: um site para quem quer ter casos fora do
>> casamento. Ao colocar e-mail e senha, tudo o que esse site pode dizer é que
>> a combinação e-mail/senha não existe no banco de dados. Afirmar que o
>> e-mail existe seria sim uma falha de segurança, com implicações
>> possivelmente terríveis para o usuário.
>>
>>
> Sim, para algum aplicação sim. Então neste caso ela não deveria ter o
> email como chave primaria do sistema dela. Você até pode argumentar em
> fazer a validação do email em 2 etapas, mas isto vai depender muito da
> aplicação e portanto não considero uma falha de segurança.
>
>
>>
>> Em 15 de setembro de 2013 23:15, Solli Honorio <shonorio at gmail.com>escreveu:
>>
>>
>>>
>>> Em 15 de setembro de 2013 21:28, Leonardo Ruoso <leonardo at ruoso.com>escreveu:
>>>
>>> Deve haver alguma aplicação onde o benefício de guardar o valor do md5
>>>> de uma string como BINARY/BYTEA em oposição ao próprio valor da string e
>>>> deixar o índice BTREE fazer seu trabalho compensará → provavelmente é a
>>>> mesma aplicação que vai notar benefício real em adotar largura fixa em
>>>> detrimento de XML para intercâmbio de dados. Felizmente eu ainda não tive
>>>> de colocar minhas mãos em nenhuma delas. Infelizmente eu já tive de lidar
>>>> com CNAB e com chaves artificiais onde cabiam chaves naturais suficientes
>>>> na minha vida…
>>>>
>>>> Acabamos de modelar aqui um sistema, em que algumas tabelas contém
>>>> milhões de registros…
>>>>
>>>> Adivinha qual vai ser a chave das regiões brasileiras (hierarquia desde
>>>> país até setor censitário passando por região, uf, meso, micro, municipio,
>>>> distrito e subdistrito)?
>>>>
>>>>
>>>> br.se.sp.regiao-metropolitana-de-sao-paulo.sao-paulo.sao-paulo.moema-indianapolis.moema.av-indianapolis-2000-2200
>>>>
>>>> Servidor com 32 cores e 64GB de RAM?
>>>>
>>>> R$ 10 mil reais por ano
>>>>
>>>> Custo de manutenção de sistemas?
>>>>
>>>> Incalculável!
>>>>
>>>> Galera:
>>>>
>>>> Chave natural é tudo de bom!
>>>> Chave composto é lindo e funciona!
>>>>
>>>> Não se esqueça que dizer para os usuários que um email já está
>>>> cadastrado permite atacar sua base de usuários :)
>>>>
>>>>
>>> Acho esta afirmação parcialmente verdadeira. Conhecer que existe um
>>> email na tua base é inevitável quando vc a está utilizando como uma chave
>>> para o sistema, e nem preciso ser um hacker para isto.
>>>
>>> Qualquer um pode saber quais são os emails que estão cadastrado no
>>> Amazon.com e no Twitter, por exemplo, mas isto não é considerado uma falha
>>> de segurança da Amazon.
>>>
>>>
>>>>
>>>>
>>>> Em 15 de setembro de 2013 17:17, Lucas Mateus <
>>>> lucasmateus.oliveira at gmail.com> escreveu:
>>>>
>>>>
>>>>>         É disso que to falando, usar o MD5 mesmo (binário) e não md5
>>>>> em hexadecimal, e acho sim muito comum emails com mais de 16 bytes.
>>>>>
>>>>>         E se executar a query já passado o email com o md5, sem
>>>>> precisar usar a função do BD é ainda melhor, ja que o BD faz o hex por
>>>>> conta própria.
>>>>>
>>>>>
>>>>> mysql> show create table users_2;
>>>>>
>>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>>>>> | Table   | Create Table
>>>>>
>>>>>                                                                    |
>>>>>
>>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>>>>> | users_2 | CREATE TABLE `users_2` (
>>>>>   `email` varchar(60) default NULL,
>>>>>   `email_md5` binary(16) default NULL,
>>>>>   KEY `idx_email` (`email`),
>>>>>   KEY `idx_email_md5` (`email_md5`)
>>>>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
>>>>>
>>>>> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>>>>> 1 row in set (0.00 sec)
>>>>>
>>>>>
>>>>> mysql> select email from users_2 where email = 'teste967847 at domain.com
>>>>> ';
>>>>> +------------------------+
>>>>> | email                  |
>>>>> +------------------------+
>>>>> | teste967847 at domain.com |
>>>>> +------------------------+
>>>>> 1 row in set (0.21 sec)
>>>>>
>>>>> mysql> select email from users_2 where email_md5 = unhex(md5('
>>>>> teste967848 at domain.com'));
>>>>> +------------------------+
>>>>> | email                  |
>>>>> +------------------------+
>>>>> | teste967848 at domain.com |
>>>>> +------------------------+
>>>>> 1 row in set (0.00 sec)
>>>>>
>>>>>
>>>>> Em 15/09/2013, às 16:44, Eden Cardim <eden at insoli.de> escreveu:
>>>>>
>>>>> >>>>>> "Lucas" == Lucas Mateus <lucasmateus.oliveira at gmail.com>
>>>>> writes:
>>>>> >
>>>>> >    Lucas>     Show Eden, mas seu teste não tem absolutamente nada a
>>>>> >    Lucas> ver com o que eu disse =)
>>>>> >
>>>>> > A única diferença do que você mostrou é que no meu caso, o campo
>>>>> > email_md5 não existe porque não precisa, o índice resolve. E eu
>>>>> > coloquei valores md5 no campo email pra ter alguma aleatoriedade no
>>>>> > teste.
>>>>> >
>>>>> > --
>>>>> > Eden Cardim -- Insolide Soluções de TI Ltda.
>>>>> > +55 11 9644 8225
>>>>> > http://insoli.de
>>>>> > =begin disclaimer
>>>>> >   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>> > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>> > =end disclaimer
>>>>>
>>>>> =begin disclaimer
>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>> =end disclaimer
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Leonardo Ruoso
>>>> Journalist, Perl developer and business consultant
>>>> Media, UFC/2006; Telecom, IFCE/1998
>>>>
>>>> =begin disclaimer
>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>> =end disclaimer
>>>>
>>>>
>>>
>>>
>>> --
>>> "o animal satisfeito dorme". - Guimarães Rosa
>>>
>>> =begin disclaimer
>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>>
>>
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>


-- 
Tiago B. Peczenyj
Linux User #405772

http://about.me/peczenyj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130916/a11ddc19/attachment-0001.html>


More information about the SaoPaulo-pm mailing list