SóProvas

ID
895216
Banca
CESPE / CEBRASPE
Órgão
CNJ
Ano
2013
Provas
Disciplina
Segurança da Informação
Assuntos

Acerca de conceitos relacionados ao desenvolvimento de software
seguro e segurança para web services, julgue os itens subsecutivos.

Ao se utilizar a tecnologia web services para garantia de uma autenticação segura, devem ser usados signed security tokens, que consistem em elementos criptografados a partir de uma chave de acesso previamente acordada.

Alternativas
Comentários
  • Errado.

    Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML

  • Deve ser usado WS-Security (Web Services Security), padrão publicado pelo OASIS, que utiliza, entre outros, certificados comuns X.509 para assinatura e criptografia das mensagens.
  • O Security Token para um web service é um reivindicação qualquer que geralmente representa a identificação do utilizador. Trata-se de uma declaração feita por uma entidade, como nome, identidade, chave, grupo, privilégio, capacidade, etc. O uso de signed security tokens. Um Signed Security Token é criptograficamente assinado por uma autoridade específica, como um X.509 certificate ou um Kerberos ticket usando uma chave privada. A questão fala de uma chave de acesso previamente acorda, é aonde está o erro. Referência: http://msdn.microsoft.com/en-us/library/ms977327.aspx
  • Os elementos criptográficos nesta questão se referem ao algoritmos de criptografia e não ao mecanismo de segurança.
  • "Ao se utilizar a tecnologia web services para garantia de uma autenticação segura, devem ser usados signed security tokens, que consistem em elementos criptografados a partir de uma chave de acesso previamente acordada."

    O problema está na porcaria do DEVEM, piora quando diz que o USO GARANTE Autorização Segura.
    Se você tem um web services usado internamente (acesso privado) o uso de tokens( qualquer token) criptografados com chave privada, publica, RSA ou qualquer outra, não importa - é peso morto - afinal se o uso é interno ou viola-se todo o sistema ou não se chega ao services, portanto a relação custo/benefício aceitável poderia ser uma intranet, se a aplicação for exposta ao mundo exterior... VPN...LÓGICAMENTE aliado a profissionais ÍNTEGROS,rss
    WebServices foi feito para troca de informações com o mundo exterior,  o nível de sensibilidade dos dados impõe a segurança admissível para uso. Por exemplo- de que adianta seu banco oferecer internet banking se restringi-la ao uso nas dependências internas do banco ? Poderiam vende-la como sistema mais seguro, mas a aceitabilidade seria no mínimo  questionável. A segurança atual do internet banking  imposta:  Quem você é,  Algo que você tem e algo que você sabe;  mesmo com essa tripla verificação, pode haver violação,rss.
    Quem você é ( user/password , biometria ), Algo que você tem( genericamente token ), Algo que você sabe( dados pessoais, token dinamico )
    Seu banco faz uso disto ? bem...o negócio deles depende disto!

    karaka, tudo isto para dizer que a resposta está errada pelo uso básico do  "DEVE" e/ou do "GARANTE" - estamos ficando NEURÓTICO 3
  • O furo mais claro e rápido de matar é falar que "as chaves são previamente acordadas". Onde viria isso? No manual do bankline?
  • Ao se utilizar a tecnologia web services para garantia de uma autenticação segura, devem ser usados signed security tokens, (errado)
        Não se tem garantia de autenticação segura apenas com signed tokens, e se o token cair em mãos erradas?
    que consistem em elementos criptografados a partir de uma chave de acesso previamente acordada. (errado)
        Eu Tenho um token e nunca acordei com ninguém uma chave de acesso
    A questão esta completamente errada!
  • Prezados,

    O enunciado da questão está mal formulado, afirmando que utiliza-se web services para garantia de uma autenticação segura, o que só por ai já deixaria a questão falsa ou passível de anulação. A questão está errada.
    Se entendêssemos que o examinador quis dizer que a fim de utilizar uma autenticação segura em um web service deveríamos usar signed security tokens que consistem em elementos criptografados a partir de uma chave de acesso previamente acordada, a questão continuaria falsa.
    De acordo com a especificação do WS-Security, um signed security token é um token de segurança que é criptograficamente assinado e atestado por uma autoridade especifica ( como um certificado X.509 ou um ticket Kerberos ) , ou seja, através de uma requisição/resposta, obtém-se um token valido. De acordo com a especificação do WS-Trust, ao solicitar o token pode ser especificado o tipo, tamanho e o algoritmo desejado, porém não há garantia que o token será gerado conforme a requisição, até porque esses atributos informados na requisição são opcionais. Vejamos a especificação:
    9.2 Key and Encryption Requirements
    This section defines extensions to the element for requesting specific types of keys or algorithms or key and algorithms as specified by a given policy in the return token(s).  In some cases the service may support a variety of key types, sizes, and algorithms.  These parameters allow a requestor to indicate its desired values.  It should be noted that the issuer's policy indicates if input values must be adhered to and faults generated for invalid inputs, or if the issuer will provide alterative values in the response.
    /wst:RequestSecurityToken/wst:AuthenticationType
    This OPTIONAL URI element indicates the type of authentication desired, specified as a URI.  This specification does not predefine classifications; these are specific to token services as is the relative strength evaluations.  The relative assessment of strength is up to the recipient to determine.  That is, requestors SHOULD be familiar with the recipient policies.  For example, this might be used to indicate which of the four U.S. government authentication levels is REQUIRED.
    /wst:RequestSecurityToken/wst:KeyType
    This OPTIONAL URI element indicates the type of key desired in the security token.  The predefined values are identified in the table below.  Note that some security token formats have fixed key types.  It should be noted that new algorithms can be inserted by defining URIs in other specifications and profiles.
    /wst:RequestSecurityToken/wst:KeySize
    This OPTIONAL integer element indicates the size of the key REQUIRED specified in number of bits.  This is a request, and, as such, the requested security token is not obligated to use the requested key size.  That said, the recipient SHOULD try to use a key at least as strong as the specified value if possible.  The information is provided as an indication of the desired strength of the security.
    /wst:RequestSecurityToken/wst:SignatureAlgorithm
    This OPTIONAL URI element indicates the desired signature algorithm used within the returned token.  This is specified as a URI indicating the algorithm (see [XML-Signature] for typical signing algorithms).
    /wst:RequestSecurityToken/wst:EncryptionAlgorithm
    This OPTIONAL URI element indicates the desired encryption algorithm used within the returned token.  This is specified as a URI indicating the algorithm (see [XML-Encrypt] for typical encryption algorithms).
     
    Não obstante, signed security token não é a única forma de se garantir autenticação segura em um Web Service, existem também a XML-Signature , XML-Encryption , SAML (Security Assertion Markup Language) [OASIS 2001]
     
     
    Fonte :
    - http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
    - http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html
    - https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf
  • Pelo que andei vendo, o principal erro está em dizer "chave previamente acordada". A assinatura de um security token tem que ser feito por uma autoridade certificadora confiável. 


    Ref: Security of E-Systems and Computer Networks, pag 162.

  • Além dos erros já citados pelos colegas, vejo outro erro: a tecnologia web service não é utilizada para garantia de autenticação segura, conforme afirma a questão!