Home » 2.3. DW Security

2.3. DW Security

WebSvcOverview

 

Web Service API Security Overview

The single front-controller web method represents the entire attack surface of the API’s, since even the admin tools and system automation logic all use the same web method to access their functionality.  The use of a front-controller service pattern acts to naturally concentrate all of the security logic for each service within a message-processing pipeline.

The request message of each API call is handled independently of the response message in order to allow for two-way authentication (the request authenticates the client to the server, and the response authenticates the server to the client).  The independent handling of the request and response messages also enables the optional asynchronous use of the API’s .  However, a SOAP one-way version of the front controller method is generally a more efficient alternative to execute asynchronous logic.  Finally, it allows for the deferred execution of method calls via queueing of the request messages, with no change to the security logic since each request message is completely self-contained.

Request and response messages sent between the client application and the web service API’s must be encrypted.  This can be accomplished by either using SSL/TLS, a VPN, or the hybrid cryptosystem built into the front controller method of the API’s.  Regardless of the type of encryption used, each request message contains a TTL timestamp to prevent replay attacks.  The hybrid cryptosystem built into the API’s is similar to PGP, but each symmetric 256-bit key is used only one time in each direction.  Request messages are encrypted so that only the specific web service called can decrypt them, and response messages are encrypted so that only the specific user account that made the method call can decrypt them.

The stateless web service API’s have no session token to be stolen, and therefore each request message sent by a client application to an web service must be individually authenticated (and each method call of the batch individually authorized).  To handle this workload, the identity store database has been built so that the authentication and authorization process only requires a single record from a single table (for maximum performance), which will be cached in memory by the RDBMS after the first such query.  In general, the performance techniques normally used by a separate session-management system have been merged into the custom identity store.

The security system itself is role-based (RBAC), and allows for the access to each API method to be controlled by role membership.  User accounts are granted access to the superset of API methods authorized for each role they have been assigned to.  Access to certain shared data within a system is authorized by a similar data group membership mechanism.  The public API methods accounts have been authorized to access are actually labels representing the functionality of a method within an internal code library.  The front controller method acts as a layer of abstraction decoupling the internal code libraries from the external web service API method (labels) being called by client applications.

Systems built using Distribware as a platform can be configured as distributed multi-computers when scaled out.  The information needed by a client application when connecting to a distributed system is too much to be memorized by a user, so keyfile is used to store that information.  The keyfile also acts as a basic password manager, so users do not have to memorize accounts and passwords either.  This functionality has led to some important modifications of the security system.

  1. The keyfile stores a security token value from each system’s identity store, to be used to authenticate the web service to the user account. These values are periodically changed and automatically updated in the keyfile similar to an account password.
  2. Each account has its own RSA public key and private keypair, which allows response messages to be encrypted so that only the intended account is able to decrypt them. The two-way authentication prevents successful Man-in-the-Middle attacks.
  3. Connection info changes, security token values, etc. are automatically updated by the central system in each user’s keyfile using encrypted System Action messages.  The ability to automatically change both the web service RSA keypair and each account RSA keypair periodically helps to mitigate RSA’s forward secrecy concerns.

 

Selected References

A.  Host OS (Windows) Security Guidelines

  1. Security Assessment Tool 4.0 : http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=12273
  2. Baseline Security Analyzer 2.3 : http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=7558

B.  Web Server (IIS) Security Guidelines

  1. Host OS security plus IIS specific security measures
  2. CIS : https://benchmarks.cisecurity.org/downloads/show-single/?file=iis8.120  ;   http://forums.iis.net/
  3. URLScan 3.1 : http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-3-reference#InstallingUrlScan

C.  Database Server Security Guidelines

  1. Host OS security plus RDMS security measures (refer to the security configuration instructions specific to each RDBMS).
  2. External access to the data stored in the database servers is only allowed via the web service API’s
  3. Only a small number of SQL Server system accounts are used to access the database via ADO.NET connection strings (mixed-mode authentication)
  4. Connection strings are stored as static configuration data, not built (connection string builders can be susceptible to injection attacks)
  5. Connection strings are encrypted, both in the .config files and in the database configuration records (using two different encryption mechanisms)

D.  Security System:  Fine-Grained Control Over Access to the API Functionality

  1. All request messages are routed into a common message handling pipeline
    • XML parsing via a secure XmlReader (tolerant reader)
    • TTL check of each request helps prevent replay attacks
    • Authentication of the request message account is a query for a single record from a single table in the security database
    • Authorization data is returned from a successful authentication query
    • The request message pipeline individually authorizes each API method call, with fine-grained control down to the version level
    • Each request message can contain 1 to N API method calls as a batch
    • Parameters from the request message API method call are mapped to concrete method parameters of an internal library method
    • Message input parameters can be scrubbed of potentially malicious characters (optional)
    • Each API method can contain 0 to N results (allows functionality similar to out parameters)
    • The results of each internal method call are tested for correctness, and the result code is set accordingly (generic attribution)
  2. A custom Identity Store (database) optimized for performance, returns authorization data for each successful account authentication
  3. Stateless web service API’s have no session token to hijack, but require each request to be individually authenticated and authorized
  4. Role-based authorization controls access to each individual API method for each user account
  5. System accounts (domain or local to server) are used to access file servers and other systems on the internal network as needed
  6. Account impersonation can be configured within the web.config file of the web service API’s (sections are encrypted)
  7. System account details can also be stored as encrypted values in the system settings table

E.  Web Service API Security

  1. DMZ Reverse Proxy
    • At a minimum, a reverse proxy acts as NAT in the DMZ, forwarding traffic to the internal load balancer IP address, while some reverse proxies have additional security features similar to routers and firewalls
  2. Configuration Data
    • Bootstrap configuration data is stored in encrypted sections of the web.config and app.config files
    • All configuration data is stored in a centralized database
    • Each value stored in the configuration database can be optionally encrypted, with the encryption key stored on a separate tier of the system (within the encrypted section of a .config file)
  3. Data Transport
    • Some form of encryption (such as SSL/TLS, VPN, or integrated) must be used to protect the content of the request messages during transport to access the web applications and web service API’s
    • The optional (integrated) data transport compression and encryption built into the API’s is an alternative to SSL/TLS or VPN
      • Both compression and encryption are optional individually
      • The hybrid cryptosystem used is similar to a simplified version of PGP, and is very strong compared to SSL and TLS
      • No CA certificates are needed, and the hybrid cryptosystem components used will never expire
      • Only the web service method parameters are encrypted (not the protocol), so the traffic appears to be unencrypted HTTP on port 80 to traffic shaping algorithms
      • Request and Response messages are encrypted separately, allowing both synchronous and asynchronous use of the API’s
  4. API Attack Surface
    • The attack surface of the web service is a single front controller method
    • There are no other internal interfaces to the API logic – only the front controller method
  5. API Abstraction
    • The publicly exposed API methods are nothing more than text labels, mapped by the controllers to real classes and methods of the internal libraries
    • The internal classes are never publicly exposed, even in the API documentation
  6. Attack Prevention and Mitigation
    • Injection and Data Attacks
      • Uses the WCF secure reader rather than the standard XML Reader
      • Uses a XmlTextReader rather than the DOM to avoid most parser exploits
    • XML Bomb
      • Request message as XML Fragment ignores the DOCTYPE elements
    • External Entity
      • Request message as XML Fragment ignores ENTITY elements
    • HTTP Session Hijacking and Impersonation
      • Stateless web service API’s have no session to hijack
    • Overflows
      • The single controller method used for all request messages accepts three string parameters, which are difficult to overflow (2 GB max size per string)
      • IIS settings plus WCF data binding quotas limit all aspects of the size of the HTTP request and XML message payload to prevent attempts to overflow the controller method
    • Input Validation
      • No concrete internal method parameters are exposed directly to the web; the request message and front controller method act as a layer of abstraction between external client applications and the internal API logic (all values are passed to the API methods as text)
      • Dangerous input data (special characters, escape sequences, scripts, encoded strings, etc.) are cleansed as part of the data validation/mapping process from strings to specific datatypes
      • Data types, sizes, are validated when mapped from the collection of request message parameters to the concrete internal method parameters
    • Code Disclosure (config data)
      • Eliminate all configuration and sensitive data from code, and store in a centralized database
      • Minimal bootstrap configuration data stored in .config files.
    • Data Disclosure
      • Sanitization of error and exception data returned to the client application
    • Replay
      • Each request message has a request timestamp adjusted to match the system clock of the API server, which has a finite (configurable) maximum Time-to-Live.
    • Denial of Service
      • IIS settings and WCF service binding quotas mitigate most types of Denial of Service attacks
    • Man-in-the-Middle
      • The custom API encryption makes it impossible to insert a transparent proxy between the client applications and the web service API’s (response message authenticates the server to the client, can only originate on the authentic API server and can only be decrypted by the specific user account).

F.  Data at Rest

  • All sensitive data is encrypted at rest either in .config files or in the various databases used by the system.  The encryption of data in the database is not provided by any of the RDBMS used by the system (separate mechanism within the API’s).
  • The encryption keys for the content are stored in the content database, but are themselves encrypted using a mechanism similar to that of the settings values. The encryption key used to encrypt the content keys is stored as an encrypted setting value.  The .config file and AppSettings encryption would both have to be defeated in order to decrypt and steal sensitive content data.

 

Testing and Metrics

The functionality of the web service API security system is best tested with the API Test functionality built into each client application.  It tests all aspects of network and API security end-to-end by virtue of running remotely like a real client application.

The security of data during transport must be tested with a network sniffer or equivalent tool.  The security of data at rest can be observed fairly easily in the system, but can only be truly tested by running a penetration test.  A good penetration test is the only way to determine the overall security of the entire system.

Example Tools:

Leave a comment