Quais são as principais diferenças entre segurança móvel e segurança web?

Muitas empresas que trabalham actualmente com segurança móvel focam-se nestes aspectos:

Gestão de Dispositivos Móveis (Dispositivos de Provisionamento/Desprovisionamento)
Segurança de Dispositivos Móveis (Correlação usuário-política e uso móvel)
Gestão de Aplicativos Móveis (Comportamento de aplicativos e correlação usuário-política)
Proteção de Dados (Aplicativo tentando roubar informações confidenciais/limpeza remota de dados)

A principal razão aqui é que não é tão fácil inspecionar e aplicar políticas sobre como um telefone móvel usa a internet em comparação com um navegador em um desktop
>>Let's olham para ele da perspectiva da Autenticação e Autorização de "AAA" (Authentication, Authorization,Audit)
<

>br>>>>p>P>P>P>Primeiro, aqui's um bom recurso contrastando segurança móvel vs segurança web.
https://www.owasp.org/index.php/Mobile_Top_10_2014-M5

Autenticação

Web
Para aplicações web, os cookies são normalmente utilizados para manter a informação de estado autenticada sobre o cliente. Os cookies talvez sejam do seguinte tipo :
(a) HTTP cookies - A visibilidade está dentro do mesmo browser
(b) Flash Cookies (LSO) - O cookie armazenado no leitor Flash é visível em diferentes browsers
(c) Evercookie - Um mecanismo apenas para garantir que todas as suas acções são rastreáveis para si.

A autenticação baseada em cookies pode ser vulnerável a ataques CSRF(Cross Site Request Forgery), XSS (Cross Site Scripting) , MITM (Man-in-the-middle ). Cada um deles é um tópico separado sobre ele's próprios. Aqui's um artigo de blog discutindo-os.
http://sitr.us/2011/08/26/cookies-are-bad-for-you.html

autenticação baseada emSAML,Identidade Federada também existe há algum tempo.

Um tópico relacionado a autenticação é a impressão digital do dispositivo.
Here's um bom artigo sobre o mesmo:
https://www.cs.ucsb.edu/~vigna/publications/2013_SP_cookieless.pdf A principal diferença aqui é que isto inclui um monte de técnicas para um terceiro determinar satisfatoriamente se você é, quem eles pensam que você é.

Móvel

O tráfego de internet móvel não é apenas através de HTTP e de um browser. As aplicações comunicam com servidores back-end. Portanto, muitas suposições que eram válidas para autenticação/rastreamento baseado em cookies don't se aplicam a aplicativos móveis.

Adicionalmente, existem diferenças entre plataformas (Android,ioS,Windows) Isto torna-se mais pronunciado se o seu dispositivo móvel precisar de ser configurado para ser utilizado numa VPN corporativa (Virtual Private Network) ou num servidor proxy.

Aqui estão alguns artigos que mostram as diferenças entre aplicativos/ aplicativos baseados em navegador,
http://www.iab.net/media/file/IABDigitalSimplifiedMobileCookies.pdf
http://www.mobileapptracking.com/docs/MAT-Tracking-Methods-For-Mobile-Apps.pdf

Aplicações móveis Android podem ser projetadas de forma reversa, e coisas como arquivos criados,API's usados podem dar um atacante da lógica cliente-servidor.

Windows Mobile Authentication: http://msdn.microsoft.com/en-us/library/994y9ec2(vs.71).aspx
ioS Authentication:
https://developer.apple.com/library/mac/documentation/security/conceptual/AuthenticationAndAuthorizationGuide/Authentication/Authentication.html - Eles falam sobre Kerberos, autenticação LDAP, entre outros.
Android/oAuth Authentication:
https://developers.google.com/accounts/docs/MobileApps .
https://developers.google.com/accounts/docs/OAuth2ForDevices

Attack Vector: Alguém rouba o seu smartphone,enraíza-o e obtém informações sobre senhas armazenadas em um banco de dados SQLite local, ou descarrega a memória do sistema para um arquivo e obtém informações sobre detalhes confidenciais como o número do cartão de crédito da memória.

AUTORIZAÇÃO

Web:
SAML realmente impõe um modelo de autorização bastante bom. Um administrador será capaz de definir regras muito facilmente para dizer que pessoas pertencentes a um determinado grupo podem acessar um determinado recurso (endpoint url de um documento/vídeo etc) . Portanto, certifique-se de que apenas pessoas autorizadas tenham acesso.

Mobile:

(1) Parte do problema resume-se à validação tanto no lado do cliente como no lado do servidor. É possível fazer engenharia reversa no lado do cliente, e acionar uma solicitação apropriada ao servidor através do emulador ou de um aplicativo modificado. Especificamente:
(a) Assumindo que uma determinada função em um aplicativo móvel será visível apenas para usuários autorizados. <(b) Assumindo que somente usuários autenticados serão capazes de gerar uma solicitação de serviço para um aplicativo móvel para ele's back-end
>>br>(2)A outra parte do problema é ofcource o intervalo de permissões que seu aplicativo solicita a você, como usuário, antes da instalação. Por exemplo, através da descompilação, análise de código estático, podemos inferir que estão sendo feitas chamadas API. Além disso, se o aplicativo for executado em um ambiente sandbox, podemos ter uma idéia do comportamento dinâmico - chamadas de rede que o aplicativo está realmente fazendo. ( Carregando seus contatos a cada 2 horas?)

Neste artigo, http://www.rsaconference.com/writable/presentations/file_upload/mbs-w01_v2.pdf , os autores dão um exemplo de um jogo andróide com engenharia reversa, que estava armazenando o número de "moedas de ouro" em um arquivo. Uma vez que o usuário foi capaz de editar e alterar o conteúdo do arquivo, o servidor fez't distinguir as alterações feitas. (Sem validação do lado do servidor).

Neste artigo, os autores falam sobre alguns vetores de ataque para aplicações móveis.
https://www.owasp.org/images/c/cf/ASDC12-Mobile_Application_Security_Who_how_and_why.pdf