This list is mainly for developers, but can be useful also for architects, security managers and testers. Mainly from design and coding perspective, enriched with configuration, operational and human process aspects.
General design principles
• Prefer to use
policy based declarative security instead of programmatic security: separation between security configuration and business code. Beware that both business code and the security configuration typically have different life cycles and implemented/managed by different people.
• Use
declarative security instead of programative, separation between application logic and the cross-cutting concerns (e.g. security, logging).
• Prefer to use
message level / end-to-end security (e.g. WSS) than transport level / point-to-point security (e.g. SSL): to protect the messages in the intermediate services and flexibility to protect only portions of the messages (due to performance).
• Does the service/data need
authentication, authorization, signature/non-repudiation,
encryption?
• If the web service is used to wrap a
legacy service: aware about vulnerabilities of the legacy service, aware about how to reconcile the security model (e.g. credentials/roles mapping) or some legacy application doesn't have any security provisioning at all
• Use
white lists instead of black lists
•
Throttling the requests / messages-size to prevent DoS
• Defense in depth:
don't rely on a
single layer of security (e.g. apply also authentication & SSL instead of protecting the infrastructure with firewall only)
•
Check at the gate (e.g. validate and authenticate
early)
• Secure the
weakest link
•
Compartmentalize: isolate and contain problems e.g. firewall/DMZ, least privileged accounts, root jail.
• S
ecure by default e.g. close all ports unless it's necessary
• Communicate the
assumptions explicitly e.g. firewall will secure all our internal services with no ports open to outside world
• Understand how the
infrastructure restriction (e.g. firewall filtering rules, supported protocol, ports allowed) will affect your design
• Understand the
organizational policies/procedure (e.g. what applications and users are allowed to do) so you don't have acceptance problem by production team because your services breach these policies
• Understand the
deployment topology due to your organization structure (e.g. your company has many remote branches offices connected to the main server-farm via VPN)
• Understand the
identity propagation / credential mapping across trust boundaries (e.g. apache web account > weblogic web service account > database account)
•
Security measures
(e.g. authentication, encryption, signing) will cost performance (increasing
processing cost and message size) as well as other qualities attributes such as
usability, maintainability (e.g. distribution of certificates) and operability
(e.g. security service / identity provider failure). So consider the trade off between security and other quality attributes
regarding your company infrastructure and policies (e.g. if the firewall policy
in your company is very strict, you might lessen the encryption requirement for the intern services).
• While applying security by design, I still keep the "security through obscurity" to some extent, e.g. I will not publicly publish the security architecture of my company (the endpoints/ports, wsdl/schema, libraries used, etc).
Security process & management
• Design & code
review (e.g. login & logout mechanism, authorization logics in each Struts actions)
• Include security in your development
process (e.g. SDL), use
thread modeling during analysis & design phase.
• Make sure that your programmers and network/servers administrators
capable to deal with security issues, arrange training if necessary.
• Make sure that the operational team know the
contingency procedure (e.g. what to do in case of DoS attack or virus spreading in your network). Have
contingency plan / crisis management
document ready: procedures to where the configurations are, how to isolate, handle failures, how to restart in safe mode, how to turn-on/turn-off/undeploy/deploy modules/services/drivers, who/how to get informed, which services/resources have priorities (e.g. telephony service, logging service, security services). Have this document in multiple copies in printed version (the intranet and printer may not work during crisis). The crisis team should have
exercised the procedures (e.g. under simulated DOS attack) and measured the metrics during the exercise (e.g. downtime, throughput during degradation mode).
• Plan team vacation such that at least one of the crisis team member
always available. Some organizations need 24/7 full time dedicated monitoring & support team.
• Hire external party for penetration testing and security audit.
•
Document incidents (root causes, solutions, prevention, lesson to learn), add the incident handling procedures to the crisis management document.
• Establish
architecture policies for your department. Establish a clear role who will guard the architecture policies and guidelines e.g. the architects using design/code review.
• For maintainability & governance:
limit the technologies used in the projects.
Avoid constantly changing technology while still open to the new ideas. Provide
stability for developers to master the technology.
• Establish
change control. More changes means more chances of failures. You might need to establish a change committees to approve the change request. A change request consists of why, risks, back-out/undo plan, version control of configuration files, schedule. Communicate the schedule with the affected parties before.
Authentication
• Prefer to use
stronger authentication (e.g. 2-way X.509 certificate authentication) than basic authentication (password based).
• If you use basic authentication use
SSL or
password digest to protect the password.
•
Credentials, authentication token / password are stored with encryption / salted
hash
• Force users to use
strong password and/or
multi factor authentication. Use password expiration feature.
•
Avoid to send
passwords to external application (e.g. when an external application need to access resource services), use OAuth instead.
•
Disable test and
example accounts.
•
Credentials (e.g. password, service accounts) are
centralized (e.g. in an LDAP server) for better manageability. Redundancy (e.g. fail-over clusters) can be used to prevent single point of failures.
• If you use certificate based certification: always check the
validity of the certificates (e.g. using CRL).
• Prevent brute-force / dictionary attacks (e.g. for add a new user webpage) using
CAPTCHA, email validation, locking after
max-attempts.
• Using
SSO / centralized security service: users don't have to have many accounts/passwords, users don't have to share their passwords with many applications/resources, the developers don't have to maintain multiple authentication mechanisms in different systems. With
federated Identity provider, you can centralized the credentials across organizations.
• Use
standard security
solutions (e.g. OAuth, OpenID, SAML to exchange security messages), don't reinvent new wheels. It's more risky to implement your own security solution than using a well tested solution.
• Authentication should be in the
server side (instead of client side/JavaScript).
• Avoid having
password as
plain text in the configuration files (e.g. fstab), save passwords in the password files / credentials files and protect these files (chmod 600 and encryption if possible).
• Beware with remote
OS authentication for example in Oracle database since an attacker can try to connect using a username that has the same name with the OPS$account in the database.
• Send confirmation when a user change his/her password, email, mobile or other sensitive personal data.
Session management
• Limit the
life time of cookie or authentication/authorization
tokens.
• Prevent
replay attack by using one time
nonce.
• Prevent
CSRF using secret
nonce as a request parameter (e.g. for OAuth) and validate the nonce in the server side, beware that a nonce cookie doesn't prevent CSRF. Prevent CSRF by informing the user about the action (e.g. "you're about to transfer $100") and ask for reconfimation/reauthentication.
•
Session ID is strongly
random generated, at least 128 bits length.
• Appropriate
logout mechanisms (e.g. invalidate sessions, clear all cookies).
• Force user to
re-authenticate for
sensitive operations (e.g. change password).
•
Hide sessionID (e.g. in secure cookies instead of in GET url parameter or hidden form field).
• Validate the security token with
HMAC or encrypt the token e.g. session ID cookies must be encrypted / using HttpOnly
secure cookies.
• Limit the
cookies domain & path.
• Always provide
logout feature. Make sure that logout is properly done (invalidate session, remove session cookies).
• Issue a
new session id for each login action (to prevent session fixation).
• Identify possible session hijacking for
multiple IP addresses / geolocation which are simultaneously use the same sessionID.
• Use
anti caching http header
(Cache-Control: no-cache and Pragma: no-cache).
• Use IE
HttpOnly to prevent client (java)scripts query the cookies.
• Set the
session timeout.
• Appropriately handle requests which indicate security check circumvention or an obvious attempt for privilege escalation,e.g. in case of requests with invalid sessionID: log the sender's IP address, invalidate the session and redirect to login page.
Authorisation
• Determine which web service
operations or which
web page/actions need authorization.
• Determine the
privilege/roles for your service/web.
• Strong
ACL (in operating system/file system level, application level, servers).
• Apply the
least privilege principle, don't use admin account for daily operations (e.g. read database), create specific accounts for specific operations (e.g. CreditcardReadOnlyAccount, UpdateInventoryAccount, WebShopInventoryReadOnlyAccount).
•
Audit/log administrator activities (e.g. create new user, grant).
• Remove the
default accounts & ACL in your system if possible (e.g. remove BUILTIN/Administrators group from SQL Server login) or
rename the default (administrative) accounts if possible (e.g. sa user in SQLServer).
• Run the server in
root jail.
•
Centralized authorization (e.g. using OAuth) to reduce the burden of reconciling different access-right in different systems across trust-boundaries (e.g. apache role=boss mapped to database role = readwriteEmployeeData).
• Using
ACL on URL tree and web methods allowed e.g. the REST url
http://myweb.kom/myprofile should only be accessible for me & myfriends only for GET method and for me only for the PUT method.
• Use ACL to protect directory and files from
transversal attack.
• Use ACL per user/session to filter direct &
undirect references (e.g. links).
•
Authorization check in all protected GUI operations (e.g. Struts-actions, Admin html page) and web service operations.
• Beware of the
system calls feature in your framework that can be used for hostile purposes, e.g. Runtime.exec() in Java or store procedure xp_cmdshell in SQLServer. Solution: root jail, least privelege accounts, ACL, disable unnecessary features, run the application server with read-only privilege on web-root directory (e.g. Apache nobody user).
• Make sure
account lockout doesn't result in
DoS.
•
Check (e.g. using a white-list) all
references submitted via input (e.g. webservice request, file, database).
• Avoid
url-jumping (e.g. Checkout -> Delivery instead of Checkout -> Payment -> Delivery) by checking the last visited page (e.g. in session variable ).
• Remove
guest account / anonymous login if it's not really needed. At least review the guest /
public account, remove
unnecessary privileges from this account.
•
Review the ACL (& authentication credential lists)
regularly to detect forgotten change actions (changed roles, departed employees)
Confidentiality, Encryption, Signing
• Encrpt/hash
sensitive data e.g. bank-accounts in the LDAP production copy used for development/test.
• Use
message-level XML-Encryption to protect sensitive data in the intermediaries / external proxies / clouds. The point-to-point SSL doesn't prevent the
intermediaries to read the sensitive data. With WS-Encryption it's also possible to e
ncrypt only a part of the messages, thus more flexible (e.g. in case the intermediary proxy need to peek the unencrypted part). The message-level security (e.g. WSS Authentication, XML-Encryption, XML-Signature) is independent to the protocols thus it offers more flexibility to send SOAP messages across
different protocols (e.g. http, jms, ftp).
• Use
signature and saved
logs for
non-repudiation
• Use
signature for message integrity
•
Protect the key (e.g. don't backup the key and the encrypted data in the same backup-tape)
• Use well-proven
encryption algorithms (e.g. AES) in well-proven libraries instead of inventing and implementation your own algorithm.
• Don't register sensitive services to
UDDI
• Use
robot.txt to avoid the sensitive files (e.g. WSDL, source codes, configuration files, confidential documents) appears in Google.
• Don't store
secrets in the client side (e.g. hidden form field, cookies, HTML5 storage). If you really need to store sensitive data in the client (or to pass them in the message): obfuscate the name and encrypt/hash the value. Beware of persistent cookies (the information will be written to the file system hence can be read by malicious users)
•
Secure backup (e.g. with encryption), store it in a secure place.
•
Avoid mixed SSL - nonSSL web sites (it causes user warning in the browser and can expose user ID.) Use CA-valid certificates (to avoid user warning in the browser).
• An example of deployment pattern: using
DMZ proxy servers between outer and inner firewall to expose (enterprise) services to public. The servers in de DMZ are treated as bastion hosts, special attentions are given to protect these servers against attacks.
• Load sensitive data
on demand,
clear them from memory as long as you don't need them anymore. Don't keep/save them (e.g. in session variables or cache) if it's not really necessary.
• Use enough
key size. Securely distribute, manage and store the keys. change the keys periodically.
Coding
•
Limit accessibility: e.g. declare classes/methods/fields as private instead of public
• Declare sensitive classes/methods/fields as
final so they can't be overwritten
• Don't write
secrets in the code (e.g. database connection string), beware that the secret strings in the compiled classes can still be read using reverse engineering tools
• R
emove test code, example code, example database
• Using
framework/library functions can be more safe than building your own function (e.g. using jquery .ajax to process json response from ajax calls instead of plainly using eval). But make sure that the third-party libraries that you use is save (e.g. code review) and follow the security newsgroup for that library.
• Use
jsp comment tag instead of html comment to avoid the code comments will be visible to the client
• Use
prepared statement for querying database to protect against sql injection (and better performance).
• If you need to
redirect via url parameter consider using mapping value instead of the actual url link. Make sure that the redirect url is valid and authorized for the user.
• Beware of
null insertion, e.g. circumvent if ($user ne "root) using user="root/0" in Perl. Solution: validate inputs.
• Beware of
buffer overflow attack (e.g. to override variables / operation address, DoS attack). Solution: use programming language/frameworks which is more safe regarding buffer overflow (e.g. Java), bounds checking
• Beware of
race condition exploitation for example to overwrite the username of another individual's session. Solution: avoid sharing variable between sessions via global variables / files / database /registry entry.
• Use CAPTCHA to distinguish genuine human inputs from robot inputs.
Configuration / operation management
• Protect /
restrict access to configuration files & admin interfaces.
•
Encrypt/hash sensitive configuration data (e.g. database connection, password).
•
Centralized security management (e.g. OPSS for Oracle Fusion Middleware, JAAS for java applications) instead of managing different configurations spreading from GUI, web services, database.
• To prevent DOS attack:
restrict message size (e.g. default 10MB in Weblogic) and set server
timeout. It's better to countermeasure DOS as early as possible (e.g. in the firewall/gateway with Cisco rate limit) before the load balancers & application servers.
• Run application-servers/database/ldap with
minimum privilege, avoid running the server as root.
• Reduce attack surface:
disable unnecessary daemons, ports, users/groups, apache-modules, network storages in the server. Disconnect
network file servers if it's not necessary
• Update the OS/applicativon-servers/database/Ldap/libraries with
latest (security) patch
• Remove the
temporary files (e.g. hibernate.properties.old or httpd.conf.bak)
• Audit/
scan regularly for
new vulnerabilities. It's not enough to do penetration test only during the first acceptance-test since the attack surface can grow with time.
• Follow the
security newsgroups/websites (e.g. BugTraq), discuss the potential new threats with your security manager.
•
Monitor the system lively for
early detection of anomalies (e.g. multiple malicious logins from a certain IP address, unusual frequent web/soap requests to a certain url). Use Intrusion Detection System (IDS).
• Change the default application
ports. Close the unnecessary ports with firewall.
• Minimize the allowed IP address source by using firewall, Apache httpd file, Weblogic connection filter.
• Use separate environments production, test, development, sandbox playground (e.g. to test prototype or try new viral algorithms.) Each components in these environments have different credentials than in other environment. If the data in the test & development are based on production data (to make the test more realistic) the sensitive production data should be masked.
• The (security)
test configuration should be identical to the production (e.g. firewall configurations, networks topology, timeout setting), for example you can use VMWork's LabManager to achieve this.
•
Hide server information in http header (e.g ServerSignature Off in apache.conf).
• Turn off
http trace feature (e.g. using Apache mod_rewrite), turn off debugging feature in production.
•
Centralized security management (e.g. in case of Weblogic infrastructure: using OWSM with security policies) for better manageability, reduce mistake.
• Use configuration
change detection system (e.g. monitor admin activities log files, Tripwire.)
Data
•
Minimum data presented to any business request
• D
on't blindly trust input data (from clients GUI/cookies, database, web service request), so always validate and sanitize the input
• Validate/preprocessing (to prevent code/SQL/command injections, XSS, DoS) in sequence:
o
canonization: transform different representation (e.g. %5c is "/" which can be used for directory transversal attack) to a canonical form.
o
sanitation: encode/escape unwanted characters (e.g. < for <).
o data
validation: validate based on white lists (e.g. XSD that defines data type/format/range).
• To
prevent DoS, XML bomb: limit input size (e.g. web service request, file upload via GUI) using gateway/server configuration, XSD restriction length, limit nested element deep, don't use maxoccurs="unbounded" in XSD. While we can also limit the message using application-server setting or XSD validation in the proxy, it's better to reject the messages as early as possible (e.g. in the gateway with XML firewall) before the message burden the load balances and application-servers.
• No security decision based on
url params (which can be manipulated by clients).
• V
alidate & sanitize output (e.g. web, database) to preven
t XSS, code injections.
• Use
output encoding for special characters (to prevent
XSS, code injections).
• Beware of
double-encode attack (e.g. \ > %25 > %255c ).
• Do not store sensitive data in
cookies.
• How to validation data input (from user input, database, external system)? How to
handle validation-error situation?
• Avoid
sensitive data in de code/scripts, config files, log files. Restrict access to these files (least privelege principle).
• Encrypt
sensitive data (e.g. employees' bank account published by LdapService).
• How do you prevent
data fishing (e.g. limit output)?
• Use
XML-firewall: faster (dedicated hardware), delegate the burden of SOA/OSB servers for validation. Reject the messages earlier for better containment and preserving performance: threat should be addressed at the edge of the network instead of at the application layer.
• Reject SOAP message with <!
ENTITY> tag (or whole DTD tag) or use SOAP 1.2 to protect against entity attacks.
• Reject SOAP message with
CDATA to avoid CDATA injection.
•
Attachment/files upload:
o limit the size
o the files must never be executed/evaluated
o anti virus check
Error handling
• Prevent
sensitive information (e.g. server fingerprinting for hackers) in the error messages. Generalized error message (to hide the implementation technology) instead of just passing the original error string from the framework (e.g. Java stacktrace).
• Don't put
human information (e.g. developer's name) in the error message to avoid social engineering exploit.
• Test and understand the
behavior of your system in case of failure / error.
•
Catch all possible errors / failures and
handle gracefully to avoid DoS.
• Appropriate
privilege level is restored in case of error / failure e.g. invalidate the session
•
Security mechanism is
still working in case of error / exceptions / DoS attack
•
Release resources (e.g. file, database pool) in case of error to prevent DoS.
•
Centralized error handling.
Logging
• Log and
monitor sensitive operations (e.g. create user, transfer money).
•
Protect log files / other files (e.g. history) which can be useful for forensic investigation using ACL, use signature if necessary.
•
No sensitive information (e.g. password) in the log, check the regulations (e.g. SOX in the US, WBP in the Netherlands).
•
Information in log: userID, action/event, date/time (normalized to one time zone), IP address.
•
Throttling the log to prevent DoS or evidence removal using log file rotation.
•
Centralized logging and standardized the logging information.
•
Audit logging regularly to detect malicious attempts using an automatic alert system. What information need to observe
signs of malicious activities? e.g. number of connections per requester IP address.
• Validate and
sanitize if you log the input (GUI form input, web service request, or external database).
• In case of attack what trail of
forensic evidence is needed (e.g. IP address of the attack messages).
•
Know your baseline (typical log file growth in
normal operation), plan log backup/removal and log rotation accordingly.
Please share your comment.
Source: Steve's blog http://soa-java.blogspot.com
References:
• Hacking Exposed Web Applications by Scambray et.al.
• How to break web software by Andrews & Whittaker
• OWASP Code Review Guide
• Improving Web Services Security (Microsoft patterns & practices) by Meier et.al
• XSD restrictions
http://www.w3schools.com/schema/schema_facets.asp
• ISO 27001, ISO 27002
