O pessoal da Ounce Labs, mais especificamente o ART (Advanced Research Team), reportou duas falhas críticas “ModelView Injection” e “Data Submission to Non-Editable fields”. Inclusive, as falhas de segurança foram exploradas e exemplificadas com a aplicação de exemplo “shopping cart” do Spring.
Resumo do primeiro problema:
E do segundo problema:
Fonte: http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1321417,00.html
Inclusive o Struts e o Webwork tiveram esse problema antes. Na real todo mundo sabia disso, que alterar parâmetros e incluindo hiddens podem modificar coisas que teoricamente não poderiam ser modificadas, mas do jeito que os caras que “descobriram” a falha (novidade!), parece mais que querem aparecer pra dizer “olha, nós, jutamente com a Spring Source, conseguimos salvar o mundo”
Pois é, são frameworks que ainda não atingiram a maturidade! Nem o JSF ainda…
Só uma perguntinha: O que é um framework maduro pra você?
Só uma perguntinha: O que é um framework maduro pra você?[/quote]
Um framework Estável, previsível, mesmo que tenha falhas são conhecidas, contornáveis e não-triviais… quer dizer, não são falhas básicas!
Resumindo, um framework de qualquer tipo que eu saiba que desenvolvendo o sistema sobre ele, esse sistema vai funcionar sem problemas!
Vejamos o Struts… é simples, tem suas falhas, mas quando corretamente utilizado dá pra fazer um sistema ágil e robusto sobre ele!
No caso do Spring… permitir que o usuário submeta informações não explicitamente autorizadas é uma falha básica e grave… isso sem contar outras falhas na integração com outras tecnologias como o RichFaces… luta-se muito para fazer a coisa funcionar…
Agora veja o exemplo do JSF, a versão 1.0 tinha brechas perigosas de segurança, o 2.0 ainda não funciona bem com o Tomahawk… quer dizer, ele ainda não cumpre bem a que se propõe. É promissor, mas ainda não dá pra colocar um sistema sobre ele com tranqüilidade, e se implementações futuras estáveis tiverem mudanças drásticas isso pode por a perder sistemas feitos sobre as versões atuais, por perda de compatibilidade…
Usar um framework assim é preocupante, eu diria até inviável!
mas se com Struts também pode fazer a mesma coisa (submeter campos que não deveriam teoricamente ser setados), o que torna ele tão seguro?
Existem milhares de sistemas feitos com SpringMVC. Se o sistema vai funcionar ou não corretamente, isso vai de programador pra programador. A quantidade de sistemas que não funcionam corretamente com Struts é tão grande quanto Spring, JSF, Webwork, Mentawai e ae por diante.
Não tem nada a ver uma coisa com a outra. Richfaces == JSF (segundo o pessoal esse problema não afetou o JSF), o dito “problema” é no SpringMVC (basta ler com atenção a notícia)
Que brechas perigosas eram essas? Além disso, JSF 2.0 ainda tá em early draft. Qualquer cara com o mínimo de noção saberia que isso nem a pau deve ser colocado em produção. Além disso, querer que o Tomahawk “funcione bem” com JSF 2.0… meu deus… O mojarra nem em versão “pré-alpha” chegou e já tem gente querendo usar com tomahawk ehauioehau Só falta me dizer que tu tá usando o JDK 1.8 
Bom, maiores informações: http://www.springsource.com/securityadvisory
Ou seja… tecnologia que não amadureceu ainda!
Tô gostando de ver que o pessoal tá usando JSF. Não que eu use (atualmente uso Struts2 - Webwork) , mas pelo menos tá seguindo pra uma padronização. Ah, e o JSF 1.2 está bem estável, não é?
Não consigo entender sua fixação com struts 1.x. Ele é horrível!!! 
Alguém poderia me informar de algum framework web que não se comporte assim por favor?
Até onde eu sei, todos são assim e isso não é de forma alguma uma “falha”, não sei de onde resolveram fazer tanto carnaval por uma coisa tão simples. Se o programador deixou uma propriedade que deveria ser privada como pública, é incompetência dele, não tem nada haver com o pobre do framework MVC.
Bem pelo que eu vi no artigo não fala qual a versão do spring, talvez a versão 2.5.5 tenha corrigido esses dois problemas,
No site do Spring explica como vc pode corrigir estes problemas:
[quote]How do I fix the problem?
To prevent the Data Submission to Non-Editable Fields issue from occurring, the DataBinder should be configured explicitly with the set of fields that are allowed for binding. To do this, set the “allowedFields” property on each DataBinder instance you work with in your application. Below is an example of how to do this with each major Controller implementation:
SimpleFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided ServletRequestDataBinder instance.
MultiActionController - Call setAllowedFields on any ServltRequestDataBinder instance you instantiate locally within a handler method body.
@Controller - Use the @InitBinder annotation to inject a WebDataBinder into a method used to configure it explicitly. Call setAllowedFields(String []) to restrict the fields allowed for that Controller class. If the set of allowedFields needs to vary per handler method, have your @InitBinder method accept a HttpServletRequest and key off the current request mapping.
AbstractWizardFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided DataBinder instance. Call getCurrentPage(HttpServletRequest) to configure the set of allowed fields per page.
To prevent the ModelView Injection issue from occurring, simply never allow the client to select the view name. View name selection is a server-side responsibility.
[/quote]
Fonte: http://www.springsource.com/securityadvisory
flwsss
Aê, quem é vivo aparece!
Pô, eu tinha esquecido como você é feio, k k k k k!
:lol: