.NET Mobile Application Development Security in Mobile and Distributed Applications

1
.NET Mobile Application Development Security in
Mobile and Distributed Applications
2
Introduction

• In previous sessions we have considered
• Design of distributed applications
• Application configuration
• Appropriate choice of technology
• In this session we will give an overview of
  security in distributed applications
• Authentication and authorization
• Encryption
• .NET support for security

3
Security Basics

• Security is important in all applications,
  particularly those
• with distributed components
• that run on mobile devices
• Need to consider all aspects of security, not
  just software
• A system is only as secure as its weakest point
• No system is 100 secure need to decide
• What level of security is required?
• What risks are acceptable?

4
Distributed Application Security

• Key aspects of distributed application security
• Only allowing access to legitimate users
• Granting users rights to perform only the actions
  they need for their tasks
• Protecting integrity and preventing disclosure of
  sensitive data
• Mobile devices are easily lost or stolen, and
  hence easily compromised
• Addressing these issues requires authentication,
  authorization and encryption
• Other issues not considered here relate to
  security compromises
• Denial of Service attacks
• Man-in-the-middle attacks, session spoofing, etc

5
Authentication Authorization

• Authentication
• Process of determining users identity
• Authorization
• Process of assigning permissions and restrictions
  to an authenticated user
• Required in a secure application, but not
  sufficient for security
• Two approaches to implementation
• Custom authentication / authorization mechanism
• Usually requires database of users, roles, etc
• Often used in systems with external components
• Can be cross-platform
• Operating system features
• e.g. Integrated Windows authentication
  authorization
• Often used for purely internal systems
• Not suitable for cross-platform applications

6
Example Windows Authentication

• Windows OS offers authentication and
  authorization facilities to the developer in
  (un)managed code
• Support for Windows authentication is automatic
  with XML Web services

using System.Web.Services using
System.Security.Principal public class AuthTest
System.Web.Services.WebService
WebMethod public String CurrentUser //
Retrieves identity of user used to // execute
this code return WindowsIdentity.GetCurrent.Name
WebMethod public String
CurrentIISUser // Retrieves authenticated IIS
user return User.Identity.Name
7
Authentication in Web Services

• Web service proxy may need to pass user
  credentials to server before being granted access
  to Web service
• Proxy.Credentials property
• Defines collection of security credentials.
• Can use
• Current users Windows credentials
• Custom credentials
• Can retrieve credentials from user via User
  Interface
• Proxy automatically passes credentials to server

SomeWebService proxy new SomeWebService() proxy
.Credentials System.Net.CredentialCache.DefaultC
redentials
SomeWebService proxy new SomeWebService() proxy
.Credentials System.Net.NetworkCredential("name"
,
"password")
8
Authorization Role-based Security

• Server needs to determine whether user has
  sufficient permissions to perform requested
  operation
• Role-based security
• Example Windows authentication
• each role corresponds to a Windows group
• System.Security.Principal namespace provides
  functions to test role membership of
  authenticated user
• e.g. Windows authentication with Web service
• No way to separate security code from application
  logic
• .NET does not provide declarative security

if User.IsInRole("Manager") // Perform
operation else throw new SecurityException("I
nvalid role")
9
Custom Role-Based Security

• Custom mechanisms possible
• Based on database of user/role information
• Needs
• database lookup to determine user identity and
  roles with every request or
• single lookup with ticketing system
• Simple, maintainable solution uses
• Stored database procedure to retrieve permissions
  for a user
• Private method in remote component which checks
  permissions using this stored procedure

10
Example Custom Role-Based Security

• Stored Procedure
• Remote component private method invokes this
  procedure, passing user name and required
  permission
• Procedure could be modified to integrate
  authentication if password supplied

CREATE PROCEDURE CheckPermission ( _at_UserName
varchar(25), _at_Permission varchar(25) ) AS SELECT
MIN (Allowed) FROM RolesPermissions INNER JOIN
Permissions ON Permissions.ID
PermissionID INNER JOIN Roles ON Roles.ID
RoleID INNER JOIN UsersRoles ON Roles.ID
Roles.ID INNER JOIN Users ON Users.ID
UsersRoles.UserID WHERE Users.UserName
_at_UserName AND Permissions.Name _at_Permission
11
Ticketing Systems

• Checking user authentication on each request is
  scalability bottleneck
• Ticketing system
• Eliminates authentication on each call
• Performs user authentication once at start of
  session if successful, issues ticket unique
  identifier for the user
• Subsequent calls only submit ticket
• Ticket validated to perform user authentication
• Ticket systems have several benefits
• Drastically improves performance if tickets
  cached in memory
• Limits security breaches to single user session
  account information not compromised
• Allows effective use of secure transports such as
  SSL
• Encrypted communication used for login
• Encryption may not be necessary to subsequent
  calls

12
Submitting Tickets

• Ticket needs to be submitted on each request
• Arranging automatic ticket submission eliminates
  messy plumbing code and simplifies development
• With XML Web services this can be implemented by
• defining custom SOAP header which encapsulates
  ticket
• custom header used on each method call ticket is
  passed automatically on each call

13
Encryption

• Authentication authorization do not prevent
  disclosure of sensitive data
• Encryption required to protect data sent across
  the network
• By default, some technologies (e.g. Web services)
  send data in plain text and are NOT secure
• Two approaches to encryption
• Use Secure Socket Layer (SSL) to provide fully
  encrypted network communications
• Gives industrial strength protection, but can be
  slow
• Not considered further here
• Selectively encrypt data using available
  cryptography mechanisms e.g. classes in the .NET
  Framework System.Securuty.Cryptography namespace
• More work for the developer but potential
  performance improvements

14
Cryptographic Algorithms

• Two distinct forms of cryptographic algorithm
  exist - both rely on strength (i.e. length) of
  key not secrecy of algorithms
• Symmetric encryption algorithms
• Single key used to encrypt and decrypt
  information
• Secret key technique key known only to
  communicating parties
• Fast but easily compromised as key value often
  has to be transmitted between client and server
• Asymmetric encryption algorithms
• Uses public-private key pair public key is
  publicly available
• Information encrypted using one of the keys can
  only be decrypted by the matching key
• Based on complex mathematical operations which
  are slow to solve
• Better than symmetric encryption but hundreds of
  times slower
• Hybrid approach
• Asymmetric encryption used to distribute random
  key subsequent interactions use symmetric
  encryption with this key
• Better performance than fully asymmetric
  operation
• More secure than fully symmetric operation

15
Selective Symmetric Encryption

• After user session authenticated, use secret key
  encryption
• Reduces processing time and message size
• Random symmetric key generated and asymmetrically
  encrypted during transmission
• Symmetric encryption uses initialization vector
• Random series of bytes added to session
• Client typically uses
• Same secret key for all sessions
• Different initialization vector for each session
• Server needs to store client key/vector
  information
• Should be stored decrypted before storing in
  memory
• Should be encrypted if placed in persistent store

16
Implementing Custom Encryption

• Custom encryption can be automatically added to
  all communications via
• Custom SOAP extension for XML Web service
• Custom encryption is often not as strong as SSL
  encryption due to lack of
• Identity verification
• SSL uses digital certificates to verify identity
• Message authentication
• SSL adds keyed hash code to every message to
  detect message tampering

17
.NET Code Access Security

• Do not overlook the Code Access Security
  mechanism of .NET
• Distinct from Windows security and similar in
  operation to Java notion of protected sandbox,
  but more dynamic
• Code can request permissions it requires
• CLR gathers evidence about assemblies
• Where it was loaded from, strong name, publisher
  certificate, etc
• Administrator can define security policy files at
  enterprise, machine and user level
• Policy sets allowed permissions based on evidence
• Permissions granted to code based on evidence
  gathered by CLR and policy definitions
• Certain actions trigger security checks
• CLR performs stack walk to verify that all
  callers have required security permissions to
  perform the action
• Prevents malicious code from tricking trusted
  code to do something on its behalf

18
Summary

• In this session we have briefly considered
  security in distributed applications
• Authentication and authorization
• Encryption
• .NET support for security

19
Reading and Resources

• Reading
• Matthew MacDonald, Microsoft .NET Distributed
  Applications Integrating XML Web services and
  .NET Remoting, Microsoft Press, 2003
• Chapter 13, pp 421 475
• Michael Howard David LeBlanc, Writing Secure
  Code, 2nd Edition, Microsoft Press, 2003
• Resources
• Microsoft Patterns and Practices
• Improving Web Application Security Threats and
  Countermeasures , http//msdn.microsoft.com/librar
  y/default.asp?url/library/en-us/dnnetsec/html/Thr
  eatCounter.asp
• Building Secure ASP.NET Applications
  Authentication, Authorization, and Secure
  Communication, http//msdn.microsoft.com/library/d
  efault.asp?url/library/en-us/dnnetsec/html/secnet
  lpMSDN.asp?frametrue