ReloTracker Application Security
Purpose: This document explains the security of the ReloTracker system, independent of where it is
hosted.
Author: David Sanders
Revised: 10 October, 2013
Status: Public
Overview
Security is more and more a concern for any organization, not only from an internal point of view but
also from a commercial perspective. No system can be made 100% secure, and many security flaws are
caused by poor practices by users. Security is not only a goal, but also a continual process. ReloTracker is
developed according to security best practices and has been tested internally and externally. A list of
common questions and appropriate responses are provided for our licensees.
Security Basics
ReloTracker is an “online system” or “web-based application”. This means that it is hosted on a web
server and users access it using a web browser. Because of this, there are many possible security issues:




The users’ computer or mobile device.
The network from which the user accesses the application, whether a company network, home
network, airport, or other public place. The type of network also matters: whether it is by cable
or wireless (Wi-Fi).
The server on which the ReloTracker system is hosted. If we are hosting your application, please
see the document, ReloTracker Hosting and Backup.
The security of the application itself, which is the subject of this document.
This document mainly addresses the security of the ReloTracker system, although you will find in
Appendix A some recommendations on how you can address other security issues. It is your
responsibility to address these other security issues.
Application Security
Best practices in application security fall into several categories:
1. Develop according to established security guidelines.
2. Enforce strict security controls.
ReloTracker Application Security
© 2013 ReloTracker
Page 1
3. Test internally for security issues.
4. Use external testing to verify security controls.
Establish Security Guidelines
Security is based on two foundations: preventing possible means of attack and following best practices.
The Open Web Application Security Project (OWASP: https://owasp.org/) is a worldwide not-for-profit
organization focused on improving the security of software. It publishes a Top 10 list of application
security issues. Please see Appendix B: OWASP 2013 Top 10 Vulnerabilities.
ReloTracker is built using Microsoft’s ASP.NET Framework, used by millions of companies to create
applications. ASP.NET has built-in features to prevent different types of attacks, like Cross-site Scripting
and Session Hijacking.
In addition to the security features provided by ASP.NET, ReloTracker has several security measures built
into its design, including.

All access is Role-based. There is no default role, so the role of every user needs to be
determined before the system shows any information.

The cookie that ReloTracker sets in the user’s browser is encrypted, so it is not possible to
understand and manipulate a cookie.

Database queries are made using parameters in the business layer, rather than simply replacing
variables, and user input is validated, to prevent SQL injection attacks.

Tracing and debugging are turned off by default.

ReloTracker requires that users have at least 6 characters in a password. Passwords are
encrypted in the database.

Solution and Project files are not stored on the web server.
Enforce Strict Security Controls
The first measure of our security controls means that we train our developers and support personnel on
the guidelines that we have put in place. They are expected to make changes to the system within those
guidelines.
The second measure of controls is that all changes to the system are reviewed before release. This
means that when a developer makes changes and submits them, that that the Director of Operations
reviews them before they are released and implemented.
Internal Testing
Despite these controls, there remains a possibility that weaknesses enter into the system. For this
reason, we conduct internal testing on a regular basis.
Tools such as the OWASP’s Zed Attack Proxy are regularly used to test for a wide range of vulnerabilities
against attacks and threat agents. See Appendix C: Penetration Testing Process.
ReloTracker Application Security
© 2013 ReloTracker
Page 2
External Testing
Occasionally we also employ an outside company to perform penetration testing of the application. This
is both to ensure that vulnerabilities are identified, and to confirm that our internal tests are identifying
any issues.
Espion (http://www.espiongroup.com/), an IT security and forensics company in Europe, was contracted
to perform this testing in September, 2013. Their Executive Summary states: “Based on the results of
this review no high priority finding has been identified”.
Proactively using ReloTracker Security
Security is often only mentioned in response to specific customer requests. Our customers do not feel
comfortable using it as a sales argument. But it can be a powerful selling tool.
Here are some statements that you might use, adjusting them according to your needs.
We track and monitor our operations using ReloTracker, the leading relocation management software. It
is used by tens of relocation companies in every part of the world.
ReloTracker is developed using proven Microsoft technologies, like ASP.NET and SQL Server. It has been
developed from the beginning according to best practices in the industry and security concerns. Some
examples of the security controls include:

Multi-tiered application development.

Encryption of passwords.

Role-based login, to restrict users’ rights.

Use of a security certificate for secure communications.

Backups are made regularly and stored encrypted in a secure, offsite location.
Until now, ReloTracker has never experienced a security problem. It is regularly tested both internally
and externally against common web application vulnerabilities.
The last two bullets only apply if your hosting meets these requirements.
We certainly do not require that you mention ReloTracker as the name of your system; you can simply
replace references to ReloTracker with “our system”.
Privacy
Privacy issues are often confused with security issues. Until there is a need for a separate Privacy Policy
document beyond those in your ReloTracker License, we state our privacy policy here:
ReloTracker Application Security
© 2013 ReloTracker
Page 3
1. You, the ReloTracker Licensee, are the Data Owner. The information in the Data Owner’s
ReloTracker system and related files and databases are completely the Data Owner’s property.
We have no right to use that information in any way except to support your use of the
application. We fall under strict European Union regulations regarding the use of personal
information.
We will notify the Data Owner by email or other means within 24 hours if the Data Owner’s
information has been or will be seized by a third party or government entity, or if we suspect
that it has otherwise been compromised.
2. Privacy policy toward users is completely the Data Owner’s responsibility. We can support you in
the display of “opt-in” or privacy agreement pages. It is up to the Data Owner to establish and
implement privacy policies in accordance with applicable laws.
ReloTracker Application Security
© 2013 ReloTracker
Page 4
Appendix A: Best Practices That You Control
There are many security aspects that we do not control. In many cases these are left under our
customers’ control for business reasons.
When a customer asks how you maintain the confidentiality and integrity of customer data, they are
also asking what policies and procedures you have in place.
1. Hosting security
It is important that the system is hosted at a facility that has good security practices in place. For
the systems that we host, please see the document, “ReloTracker Hosting and Backup”.
2. Security certificate
A security certificate allows your system to run under Secure Sockets Layer (SSL, https://), which
means that all information communicated between users’ machines and the server are
encrypted. Wi-Fi connections to the internet using public hotspots are not secure, which mean
that information which is not encrypted could be intercepted. We have been recommending
strongly that ReloTracker only be hosted using a security certificate.
3. Password complexity
In ReloTracker passwords must be at least six characters long, but the length of the password is
not the most important matter. KBZ*42 is a good password; princess1973 is not. A good
password should be neither predictable nor common.
a. People that know you should not be able to predict your password. Ann2013 is a
terrible password, as is anything involving the names of your partner or children, and
birth years.
b. Hackers have lists of the top million passwords, gained from systems that they have
hacked. Almost anything you can construct, like peterj56, will likely be included in that
million that they might try.
c. Random letters, numbers, and punctuation are much better passwords. Think of a
sentence, like, “5 flying fishes eat 7 insects. Yum!” A password based on that could be
5ffe7i.Y! – a great password!
d. ALL users of the system should be given complex passwords.
4. Shared passwords
We have seen systems in which several Internal Users have the same password. What happens
when you need to fire someone, and they become upset? It should be absolutely against your
policy to use the same password, or to allow users to tell others their password. We cannot be
responsible for security issues caused by this.
5. Administrator rights
Users that are part of the Administrator Role can view and change passwords and other secret
company information. You should only allow a very small number of people to have
Administrator rights. It is possible to allow a non-Administrator to view certain Administration
pages, like Currencies. Contact Support for more information.
6. Menus/Rights
It is under your control and responsibility to ensure that internal and external users have
appropriate rights to view and change information. This is discussed in the ReloTracker
Administrator’s Guide. Please contact Support with any questions.
ReloTracker Application Security
© 2013 ReloTracker
Page 5
7. Limit login attempts
It is possible, although not the default setting, to limit the number of login attempts by users.
This can be used to prevent “brute force” attempts, where hackers try many passwords. This
setting is found on the Main>Administration>Settings page, near the top of the page. The
Default setting is 0, which means unlimited login attempts. You can set it to five, ten, or
whatever number you think is reasonable.
ReloTracker Application Security
© 2013 ReloTracker
Page 6
Appendix B: OWASP 2013 Top 10 Vulnerabilities
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted
data is sent to an interpreter as part of a command or query. The attacker’s
hostile data can trick the interpreter into executing unintended commands or
accessing data without proper authorization.
Application functions related to authentication and session management are
A2-Broken
often not implemented correctly, allowing attackers to compromise
Authentication and
passwords, keys, or session tokens, or to exploit other implementation flaws
Session Management
to assume other users’ identities.
A3-Cross-Site Scripting XSS flaws occur whenever an application takes untrusted data and sends it to
a web browser without proper validation or escaping. XSS allows attackers to
(XSS)
execute scripts in the victim’s browser which can hijack user sessions, deface
web sites, or redirect the user to malicious sites.
A direct object reference occurs when a developer exposes a reference to an
A4-Insecure Direct
internal implementation object, such as a file, directory, or database key.
Object References
Without an access control check or other protection, attackers can manipulate
these references to access unauthorized data.
Good security requires having a secure configuration defined and deployed
A5-Security
for the application, frameworks, application server, web server, database
Misconfiguration
server, and platform. Secure settings should be defined, implemented, and
maintained, as defaults are often insecure. Additionally, software should be
kept up to date.
Many web applications do not properly protect sensitive data, such as credit
A6-Sensitive Data
cards, tax IDs, and authentication credentials. Attackers may steal or modify
Exposure
such weakly protected data to conduct credit card fraud, identity theft, or
other crimes. Sensitive data deserves extra protection such as encryption at
rest or in transit, as well as special precautions when exchanged with the
browser.
Most web applications verify function level access rights before making that
A7-Missing Function
functionality visible in the UI. However, applications need to perform the
Level Access Control
same access control checks on the server when each function is accessed. If
requests are not verified, attackers will be able to forge requests in order to
access functionality without proper authorization.
A8-Cross-Site Request A CSRF attack forces a logged-on victim’s browser to send a forged HTTP
request, including the victim’s session cookie and any other automatically
Forgery (CSRF)
included authentication information, to a vulnerable web application. This
allows the attacker to force the victim’s browser to generate requests the
vulnerable application thinks are legitimate requests from the victim.
A9-Using Components Components, such as libraries, frameworks, and other software modules,
almost always run with full privileges. If a vulnerable component is exploited,
with Known
such an attack can facilitate serious data loss or server takeover. Applications
Vulnerabilities
using components with known vulnerabilities may undermine application
defenses and enable a range of possible attacks and impacts.
Web applications frequently redirect and forward users to other pages and
A10-Unvalidated
websites, and use untrusted data to determine the destination pages. Without
Redirects and
proper validation, attackers can redirect victims to phishing or malware sites,
Forwards
or use forwards to access unauthorized pages.
Source: https://owasp.org/index.php/Top_10_2013-Top_10
A1-Injection
ReloTracker Application Security
© 2013 ReloTracker
Page 7
Appendix C: Penetration Testing Process
ReloTracker Application Security
© 2013 ReloTracker
Page 8
Appendix D: Frequently Asked Questions
Here are examples of questions that have been asked by employers and RMCs in RFPs/RFQs, and the
appropriate responses.
Technologies and Development
What code development tools and technology do you use?
The application is mainly written in C#, with some JavaScript. We use Microsoft Visual Studio as the
development environment.
Which application server technologies are used?
Microsoft ASP.NET 3.5 or later.
Which database server technologies are used?
Microsoft SQL Server 2008 or later.
What is the application architecture?
It is a three-tier architecture. User input is not sent straight to the database, but is replaced by
parameters in the business layer.
Is a Software Development Life Cycle (SDLC) process in place?
It is documented and formally adopted. ReloTracker is developed according to Agile Development
principles.
Do error conditions that occur during normal operation limit display of detailed system information?
Yes, tracing, debugging, and verbose error messages are turned off by default.
Authentication
How is application authentication performed?
There are defined roles for internal and external users. Each role is associated with the ability to see
certain information and perform certain actions. There is no default role, so when a user logs in, the
system must be able to positively identify their rights.
Are application account passwords stored encrypted?
Yes, using AES Encryption with SALT
Does the application use cookies?
Yes, an application like this must use cookies. Our cookie is encrypted so that it can only read by the
application.
Does the application mark cookies as secure?
ReloTracker Application Security
© 2013 ReloTracker
Page 9
Yes.
Do the application URLs contain login IDs and/or password hashes?
No, this information is never included in the URLs.
Are users are required to re-authenticate before performing sensitive transactions?
The system does not include highly sensitive transactions, like the processing of credit card payments.
Is the application compatible with Windows Integrated Security or other Single-Sign-on (SSO)?
No, because these methods require that all users be part of a single organization or network. Users of
ReloTracker (Transferees, HR, field consultants) are members of different organizations, and so cannot
be managed under this system.
Is it possible to force password changes?
Not currently, but scheduled for implementation in 2013.
Information Security
Has the application code undergone internal and third-party security review?
Yes, internal security reviews are conducted monthly. The application has had an independent thirdparty security review within the last six months.
What do the security reviews cover?
The top-ten OWASP issues, including user input validation, error and exception handling, SQL and SSI
injection, JavaScript injection, XSS (Cross-site scripting), predictable resource location and path traversal.
Does the application run with administrator or root privileges?
No, it runs with web user privileges.
Do any fields have any additional protection (for example, repeated data entry, cross checked
calculations, etc.)?
In accordance with database design standards, many fields contain redundant data to prevent important
information, like invoice details, from being overwritten.
What is the process for changes to the application software?
Major changes – those that involve development rather than simple customizations – must be approved
by the Director of Operations. They are assigned to a software engineer, with notes on implementation.
The software engineer makes the changes and passes them back to the Director of Operations for
acceptance testing, including security review.
Can you provide access to logs to detect all actions performed by administrators or users?
ReloTracker Application Security
© 2013 ReloTracker
Page 10
High-level activities like adding or deleting a transferee and status updates are logged by user. Low-level
changes, like changing a field are not always logged. If there were an incident, we would cooperate by
providing logs to help uncover the extent of the activity.
ReloTracker Application Security
© 2013 ReloTracker
Page 11