Arquivo

Posts Tagged ‘bind’

Problema com Bind em ListPicker.SelectedIndex

Utilizando uma classe View Model para fazer um “one way” ou “two way” bind na propriedade SelectedIndex de um List Picker é levantada a seguinte exceção: “SelectedIndex must always be set to a valid value.”

Tomando como exemplo o seguinte cenário:

Código XAML:

<Grid x:Name="LayoutRoot">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>

    <toolkit:ListPicker
        Grid.Row="0"
        x:Name="List1"
        SelectionChanged="Picker_SelectionChanged"
        SelectedIndex="{Binding PickerSelectedIndex, Mode=TwoWay}"
        ItemTemplate="{StaticResource PickerTemplate}"
        ItemsSource="{Binding MyList}"/>
</Grid>

E o código no DataContext da página:

 private ObservableCollection<MyClass> myList = null;
    public ObservableCollection<MyClass> MyList
    {
        get { return this.myList; }
        set
        {
            if (value != this.myList)
            {
                this.myList= value;
                NotifyPropertyChanged("MyList");

                this.PickerSelectedIndex = 0;
            }
        }
    }

    private int pickerSelectedIndex = 0;
    public int PickerSelectedIndex
    {
        get
        {
            return this.pickerSelectedIndex;
        }
        set
        {
            this.pickerSelectedIndex= value;
        }
    }

Solução:

Aparentemente, no processo de conversão do XAML em objeto, o ItemsSource deve aparecer antes da propriedade SelectedIndex, isso deve resolver o problema.

<toolkit:ListPicker
    Grid.Row="0"
    x:Name="List1"
    SelectionChanged="Picker_SelectionChanged"
    ItemTemplate="{StaticResource PickerTemplate}"
    ItemsSource="{Binding MyList}"
    SelectedIndex="{Binding PickerSelectedIndex, Mode=TwoWay}"/>

Evitando Bind Injection com ASP.NET MVC

O título do post é sensacionalista, mas o conteúdo é sério.
O recurso de model binding nativo do ASP.NET MVC, oferece um sério risco, dependendo da forma que o desenvolvedor utilize o binding automático.

Imaginemos o seguinte senário:

Uma action que grava alterações no nome e e-mail de um usuário do sistema.
Há diversas formas de capturar no servidor os dados enviados pelo cliente.

Exemplo 1: Declarando na assinatura do método os parâmetros correspondentes aos campos postados no form:

public ActionResult Gravar(string Nome, string Email)
{
   // código de persistência
}

Exemplo 2: Obtendo os dados pelo objeto Request que contém os dados postados:

public ActionResult Gravar()
{
   string nome = Request["Nome"];
   string email = Request["Email"];
}

Exemplo 3: Setando o tipo do parâmetro para a classe que contém esses membros.

[HttpPost]
public ActionResult Gravar(User usuarioPostado)
{
   // código de persistência
}

Classe de domínio:

public class User
{
  public int Id { get; set; }
  public string Nome { get; set; }
  public string Email { get; set; }
  public bool IsAdmin { get; set; }
}

imagine que você criou uma view fortemente tipada, usando o gerador automático do Visual Studio, e sua view contém um campo que permite alterar a propriedade IsAdmin.

</pre>
<div class="editor-label">@Html.LabelFor(model => model.IsAdmin)</div>
<div class="editor-field">@Html.EditorFor(model => model.IsAdmin)
 @Html.ValidationMessageFor(model => model.IsAdmin)</div>
<pre>

Certamente você vai remover esse campo, ou marcá-lo como read only e deixá-lo lá na view.

Vulnerabilidade:
Alguém mal-intencionado pode postar essa informação livremente via GET, ou com um pouquinho mais de trabalho via POST, basta saber que existe esse campo no BD, e que o campo tem o nome de “isAdmin”, setar IS ADMIN = TRUE, e OBTER PERMISSÃO DE ADMINISTRADOR no seu sistema quando os dados forem persistidos.

Possíveis defesas:

Defesa 1: Utilizar o atributo Bind na classe de domínio.

[Bind(Exclude = "IsAdmin")] // É possível usar a propriedade Include, que informa quais membros são permitidos, ao invés de quais serão excluídos.
public class User
{
  public int Id { get; set; }
  public string Nome { get; set; }
  public string Email { get; set; }
  public bool IsAdmin { get; set; }
}

Defesa 2: Utilizar o atributo Bind no método de gravação.

[HttpPost]
public ActionResult Gravar([Bind(Exclude = "IsAdmin")] User usuarioPostado)
{
   // código de persistência
}

Defesa 3: Utilizar uma ViewModel para trocar dados entre a view e o seu controller:

public class UserInputViewModel
{
  public int Id { get; set; }
  public string Nome { get; set; }
  public string Email { get; set; }
}

[HttpPost]
public ActionResult Gravar(UserInputViewModel usuarioPostado)
{
   // converte a classe UserInputViewModel => em User
   // Uma dica é usar a biblioteca AutoMapper: https://github.com/AutoMapper/AutoMapper
   // efetua a persistência.
}

Existem mais defesas possíveis, e uma dica interessante que aprendi é:
“Trate qualquer HTTP request como malicioso até que se prove o contrário.”.

Fontes:
IronShay | Mass Assignment Vulnerability in ASP.NET MVC

6 Ways To Avoid Mass Assignment in ASP.NET MVC

Guia Ecológico

Despertando a consciência que preserva!

Viagem e Voo

Dicas para viagens, férias e voos nacionais e internacionais

Ivan Guimarães Meirelles

Analista Desenvolvedor

Void Podcast

Vazio e sem retorno de valor

Elemar DEV

Negócios, tecnologia e desenvolvimento

2,000 Things You Should Know About WPF

Everything a WPF Developer Needs to Know, in Bite-Sized Chunks

Gabriel RB.net

Blog técnico, com dicas, códigos, novidades e problemas do dia-a-dia programando.

Alexandre Valente's Blog

Experiências em tecnologia e assuntos diversos

%d blogueiros gostam disto: