WEB SERVER AND SENDSAFE SECURITY
The server that hosts SendSafe JSOF web pages and the computer that runs the SendSafe JSOF Robot must maintain solid levels of security. If the people maintaining your web site cannot be trusted or are ill-informed in security issues, then the security of your e-commerce system is comprised. Most successful theft occurs with inside help. Make sure that only trusted employees have access to the SendSafe JSOF system. If a criminally minded individual obtains physical access to the computer running the SendSafe JSOF Robot then little can be done to prevent theft. Thirty-seven percent of all robberies occur through the front door.
BUILT IN IDS (Intruder Detection System)
SendSafe has a build in IDS system. This system can detect and block many kinds of hacker activities including brute force customer id attacks. Part of the IDS system includes the SendSafe robot performing continuous security patrols of the system and web sites.
What is detected and (or) protected:
The SendSafe system is fully operational behind single or layered firewalls. It is highly recommended that the build in IDS system be used in conjunction with a dedicated firewall which is used for general protect of all servers. The IDS system can be easily integrated with other security systems to form an even broader means of defense.
When a customer changes their e-mail address they will be issued a change of address e-mail notice to both the new and the old address. This change or address notice is part of the security system and help to make it less likely that someone will successfully steal or use someone else's account. Administrative message are also sent when change of e-mail address occurs during placement of orders (that meet certian criteria).
Servers that are collocated at a hosting company may not be in a truly secure environment. Other collocated servers on the same network as your server present security risks. These other collocated servers could be running hacker programs (either with or without the knowledge of the owner of these other servers). It is therefore strongly recommended that a firewall be erected between your server and the network. This firewall can be a stand-alone box (best solution) or a Personal/Single Machine firewall running on the server itself. The need for this firewall is to help to prevent any intentional network access to your server. The firewall should block all access except the standard Internet protocols that are needed for Internet access to your server (i.e. http, https, etc). All network access to database servers, file system, FTP/Http remote Admin, etc. must be blocked.
C Prompt provides secure hosting at it's facilities. We do not permit customer collocated servers that are not completely isolated by firewalls and other security measures (see C Prompt Hosting Service for additional information).
Access to the security components (files) housed on the web server must not be made easy. To this end http directory browsing, Gopher access, and anonymous ftp access must be disabled to the web site (with the exception of the "orders" virtual directory). If you are running the SendSafe JSOF Robot on a computer other than the server, you may need ftp access if direct file sharing is not available. This ftp access should be as restrictive as possible with the "ideal arrangement" being ftp access granted only for the IP address of the SendSafe JSOF Robot.
Http Directory Browsing is a way of getting a directory-like list of all the files on a server. From this listing an intruder can select any file for download (including personal information that is normally not in a downloadable format). This is a very basic web server security issue. If directory browsing is enabled then it becomes far easier to break into a web site. If your server has http directory browsing enable, ask your web administrator to disable it.
HTML Orders Virtual Directory Access
The OPTIONAL html orders virtual directory is a location where html copies of orders are stored and browsed. Credit card numbers are not included. This directory typically allows directory browsing. This directory should use maxium security.
Access to the SendSafe database is a requirement (see Database accounts for more info). There are two separate databases in SendSafe. The main database is typically given read/write access from the web. The credit card number database should never have read or write access from the web.
The specific methods used to configure restricted access to a database vary from database to database (SQL Server, Oracle, etc) and as such are beyond the scope of this document.
The SendSafe - JSOF Robot should never be installed in a location on a server that is accessible to http, ftp, file sharing, or any other means of remote access from the Internet. This point cannot be stressed strongly enough. The robot maintains log and configuration files which could indirectly aid a hacker in breaking into your system. Also, the default installation of SendSafe would store customer orders on the server. All SendSafe log, data, and customer order files can be configured to be stored on a different machine through file sharing.
Do not allow unrestricted access to you computer equipment. The vast majority of computer theft occurs not over the Internet, but by employees or visitors which have gained physical access to the computer where the theft then occurs.
Never publicly post documents that detail the scheduling of security tasks that the robot performs.
SendSafe JSOF system fully supports any level of encryption that is at the https protocol layer or lower; this includes SSL (secure socket layer) encryption.
NETWORK MONITORING AND SNIFFERS
Network monitoring can only occur when the code-breaker has actual access to the same network segment that either the web server or customer is on (or the code-breaker must have access to the Internet backbone). This access will not work over modems and requires actual LAN connectivity to the Internet (by the criminal’s computer or a program inserted into the network by the criminal). This means that in almost all cases a code-breaker who is using a sniffer is an employee of the ISP or the Internet backbone provider (ATT, Sprint, MCI).
A sniffer on a network backbone will produce a very large amount of uncollated data. This make SendSafe JSOF code-breaking very difficult or impossible. The most likely code break would occur from ISP employees with direct access to the web server and e-mail server.
ZDI and EDI URL Parameters and Operation
see also Database Maintenance
EDI
EDI is a customerId-token which is assigned before a visitor has logged in to the system.
The EDI is only good for Application("EDIEncryptorTTL") minutes.
The EDI token is saved in:
ZDI
ZDI contains an encrypted EDI. The EDI is only good
for Application("ZDIEncryptorTTL") minutes.
If the EDI has expired then the ZDI is considered void.
StateControl Table
smartGetStateControlObject() is used to retrieve information from the statecontrol table.
This table is used to remove dependency of saving this info in cookies.
List of current record types:
Encryptors
Encryptors are GUID values. The history of all used encryptors can be found in the statecontrol table in CID=0 records.
It is because the encryptors are GUIDs that the ZDI/EDI collisions are avoided. Should an encryptors repeat, there is
a very small, but possible chance of a ZDI/EDI collision.
The variable "ZDIEncryptorTTL" defines how many minutes an encryptor is valid (the default is 360). When an encryptor is updated, the prior valule is retained and is used for decryption but not encryption. This prior encryptor will be discarded once the current encryptor is invalidated; at that time all prior EDI and ZDI values are null and void forever. In otherwords, any ZDI/EDI value older than 2 x ZDIEncryptorTTL is void.
LogonToken
This record is used to convert EDI/ZDI values into the customerId. It is a lookup
table into which an EDI/ZDI is put to pull a customerId. If a LogonToken record is deleted it
will allow reuse of the EDI/ZDI. This potentially would allow an old saved URL with an EDI/ZDI
to log in as some else (who is used the released token). This type of collision is prevented in two ways:
The logintoken can be very useful for determining who is logged into the system. The token timestamp is updated everytime a page is loaded.
The token has a TTL controlled by Application("EDIEncryptorTTL"). The default value is 20 minutes. After the TTL expires, the token will no longer be used. It effectively becomes a placeholder.
LogonSession
This record is linked with LogonToken. It is used to pull current SessionID
and ServerID information. This record can be freely deleted as long as the LogonToken will no longer be used.
Eventlog
Anything older than 7 days is fair game for purging from the DB.
A secondary eventlog table is setup can be setup on a different DB Server. This table is named by default EventLogHist.
This table is identical to EventLog, but is maintained and used solely for reporting and as such does
not affect day to day site performance. Data from Eventlog should be moved to eventlog history periodically
using an SQL Script run as a DTS job.