22 de setembro de 2010

Hackers que descobriram a vulnerabilidade estimam que 25% de todos os sites estejam sujeitos a ataques devido ao problema.

Microsoft alerta para falha crítica que atinge aplicações em ASP.Net

Por Computerworld (EUA)

Hackers que descobriram a vulnerabilidade estimam que 25% de todos os sites estejam sujeitos a ataques devido ao problema.

A Microsoft alertou na última sexta-feira (20/09) que uma falha crítica no ASP.Net – ambiente de programação em servidores Windows – poderia ser usada por hackers para invadir páginas criptografadas da Web e roubar dados como nomes de usuário e senhas.

A vulnerabilidade se tornou pública neste mesmo dia, pouco antes do anúncio da empresa, quando dois pesquisadores, que descobriram o problema, mostraram como explorá-lo em uma conferência de segurança realizada em Buenos Aires, Argentina.

De acordo com o comunicado da companhia de Redmond, a falha atinge todas as versões do ASP.Net. Portanto, uma correção terá que ser providenciada para todos os sistemas operacionais ainda suportados, do Windows XP Service Pack 3 (SP3) e Server 2003 ao Windows 7 e Server 2008 R2. Outros produtos, como o IIS e o SharePoint também serão atualizados.

Os hackers responsáveis pela demonstração, Rizzo e Duong, disseram que os ataques que exploram a falha podem acessar aplicativos Web com prioridade administrativa, provocando desde a "perda de dados sigilosos à destruição completa do sistema". Eles estimam que 25% de todos os sites usem o ASP.Net.

Enquanto a correção não vem
Embora a Microsoft tenha dito que uma correção está a caminho, ela não divulgou um cronograma. Enquanto isso, sugere aos desenvolvedores uma medida paliativa:

"Você pode se prevenir ao ativar o recurso customError do ASP.Net, e configurá-lo para sempre retornar a mesma página de erro – independentemente da falha encontrada no servidor", escreveu Scott Guthrie, responsável por algumas equipes de desenvolvimento da empresa, inclusive a que comanda o ASP.Net. "Ao direcionar todas as páginas de erro a um único lugar, você impedirá que um hacker distinga entre os diferentes erros ocorridos".

O diretor de operações de segurança da empresa nCircle Security confirmou que a vulnerabilidade é "preocupante".

"Quanto aos serviços públicos, as pessoas ficarão temerosas com ataques que poderão acessar qualquer documento. Por exemplo, arquivos 'web.config', nos quais estão contidos o tradicional usuário/senha".

Para ajudar os desenvolvedores, a Microsoft publicou um script em Visual Basic capaz de detectar a vulnerabilidade em aplicações ASP.Net, além de disponibilizar um fórum exclusivo para as perguntas referentes ao problema.

(Gregg Keizer)

Projeto E-Lixo Maps


E-Lixo Maps

http://4.bp.blogspot.com/_eMvdTkJQxOk/S9eJrXz5BPI/AAAAAAAAHBY/O8yS6jL3FIA/s200/e+lixo.jpg

 

 

O governo do estado está investindo para que o lixo eletrônico, também conhecido como e-lixo: monitores, celulares, pilhas e demais produtos que não são considerados lixo comum, tenham um local  apropriado para serem descartados.Como esse tipo de lixo não pode ser jogado nas lixeiras comuns, o governo criou um projeto para informar a população onde levar o seu e-lixo.

No site http://www.e-lixo.org/, inserindo o CEP e o tipo de e-lixo que vai para o descarte, é possível encontrar todos os locais mais próximos de sua casa que recebem e reciclam esse tipo de resíduo. O projeto associa a plataforma do Google Maps com um banco de dados dos postos de coleta de e-lixo em São Paulo.

O projeto prevê ainda o cadastramento de mais pontos de coleta.

O programa é uma parceria da Secretaria do Meio Ambiente do Estado de São Paulo e o Instituto Sérgio Motta e o site está no ar desde o começo do mês de março.

Fonte: Portal do Governo do Estado de São Paulo.

 

17 de setembro de 2010

Depois do POG agora é a vez do eXtreme Go Horse !!!!!!!!!!!!!!!!!!!!!!



---------- Mensagem encaminhada ----------
De: Rafael Yoshio Koga <rafaelkoga@unimed.com.br>
Data: 17 de setembro de 2010 14:56
Assunto: Depois do POG agora é a vez do eXtreme Go Horse !!!!!!!!!!!!!!!!!!!!!!
Para:


 

eXtreme Go Horse (XGH)

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG's exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.


Definição da palavra Tenso

11 de setembro de 2010

6 de setembro de 2010

ótima quem escreveu merece o prêmio


 

O GOVERNANTE ANTES DA POSSE

Nosso partido cumpre o que promete.
Só os tolos podem crer que
não lutaremos contra a corrupção.
Porque, se há algo certo para nós, é que
a honestidade e a transparência são fundamentais.
para alcançar nossos ideais
Mostraremos que é grande estupidez crer que
as máfias continuarão no governo, como sempre.
Asseguramos sem dúvida que
a justiça social será o alvo de nossa ação.
Apesar disso, há idiotas que imaginam que
se possa governar com as manchas da velha política.
Quando assumirmos o poder, faremos tudo para que
se termine com os marajás e as negociatas.
Não permitiremos de nenhum modo que
nossas crianças morram de fome.
Cumpriremos nossos propósitos mesmo que
os recursos económicos do país se esgotem.
Exerceremos o poder até que
Compreendam que
Somos a nova política.


DEPOIS DA POSSE:

Basta ler o texto, DE BAIXO PARA CIMA....