| 1.6.01 Single Program Application Stack: | | Single Program Application Stack (SPAS) is an architecture designed for very secure application service provision - each web server has a single program in its application stack to minimise the security surface that can be attacked. | | The highly resilient Three-Tier Architecture has a web server application stack that contains one "index" program and no other programs as the most effective secure application stack with minimum security surface. Hackers have only one program to attack and we have only one program to build and verify as secure from all kinds of attack strategies. |
| Legal: | | Web server software is subject to an Apache license version 2.0 and associated notice that are stored in the root directory as LICENSE and NOTICE. |
| Encryption: | | The single program has an encrypted URL to pass information via links and as the same program both encodes and decodes the encrypted URL, it can dynamically change security keys. | | SPAS with its encrypted URL is a generation ahead of many web sites and that fact can easily be verified by monitoring the application stack of competitive web sites. |
| Field Update: | | The Single Program Application Stack (SPAS) architecture with its encrypted URL is inherently very secure and is reused for every real-time field update. A JavaScript function gets the new field value and appends it to the URL. Most of the information in the URL is encrypted and very secure, but the appended field value must be formally validated in detail - this is a big potential threat. The security risk is small, because even a defect in this function could never provide any secure data back to the hacker - its a database update only function. The biggest threat is SQL injection using a note field of up to 1000 characters - all special control codes that could be used for SQL injection must be eliminated. Finally, each apostrophe that is used as a field terminating control character is changed to a top-hat character - this cannot be hacked even using hexadecimal or binary control codes. |
| | | Security: | | Every web program creates a potential vulnerability that needs to be tested after every program change, so SPAS eliminates the requirement for many programs in an application stack. By reducing the security surface to a single "index" program, the program vulnerability and security threat is minimised and the cost of continually retesting the application stack is minimised. | | * New vulnerabilities cannot be introduced when new services and functions are deployed. | | * New vulnerabilities cannot be caused by new programs - programs have been avoided. | | * Security costs do not increase as the scope of the application service increases - the security surface remains unchanged. | | * Penetration tests are reduced to the verification that traditional SQL Injection and Cross Site Scripting attacks on the single "index" program shall be detected, shall be stopped and the user will be blacklisted. |
| Email: | | Email is triggered by a click on an icon or button - a JavaScript "program to result" function is employed to process the event. "Program to Result" function has 2 parameters, the first is the normal encrypted URL and the second is the ID of a field in the HTML - this information can be seen on any client computer, but does not create a security threat. The encrypted URL contains secret information that cannot be changed without detection and instant blacklisting. The field ID could be changed to any other value to change where the reply message is shown with no significant consequence. | | Email has been designed to be safe, to be very secure and to resist any hacking attack. Every email request is double recorded in the "What Did I Do" audit trail and history of the emailed record. It is not possible to hide when an email has been sent and it is not possible say that an email has been sent when it is not recorded in both audit trails. |
| Function Numbers: | | Function access control is merged over the top of data access control in a matrix that no hacker can attack. A Agent is assigned service numbers 3001 to 3999 and an Owner service numbers 6001 to 6999. No matter what Cross Site Scripting attack a Agent hacker tries, they can only use a service number 3001 to 3999 and could never impersonate an Owner - and visa versa. More than 200 service numbers have been assigned in the application service, but each user is restricted to a subset that are inherently secure from impersonation attacks. | | While document number 3121 may be functionally identical to document number 6121, only a Agent can see document 3121 and only an Owner can see document 6121. Functional security does not permit an authorized person to request an Owner document and visa versa. |
| | | Obfuscation: | | Smoke and mirrors are employed to advise the hacker to try another web site. The web site may report its infrastructure is running Windows Server 2008 service pack 2, when in fact it is running Centos Linux release 4.5. The web site may imply it is using Oracle MySQL version 1.2 when in fact it is using IBM DB2 version 9. The web site may state it is using Apache 1.2 when in fact it is using Apache 5.25. | | This is a serious game that is played with potential hackers that is continually changed so a real profile of a web site cannot be detected. Where a hacker is aware of a vulnerability in Windows Server 2008, they may try to use that defect that has no impact on the real Centos Linus operating system that is actually in use. |
| Honeypot Traps: | | Obfuscation is extended with the use of honeypots of imaginary security loopholes that act as a hacker trap. For example; "key=12345" may be hidden in a URL as a hacker trap. A hacker using special Firefox extensions will be able to detect this key value and change its value in the same way as many published program vulnerabilities. However it is a deliberately designed honeypot that will attract hackers to make an attack where they will be detected, stopped and blacklisted. | | By properly understanding published program vulnerabilities that are used by hackers, those same methods can be used to detect and blacklist hackers. A penetration tester could look at the application and imagine all kinds of self-evident program vulnerabilities, but they will discover these are just honeypot traps that will instantly blacklist any hacking attack. |
| Penetration Tests: | | It is very difficult for a professional white-hat security consultancy to undertake regular penetration test because only a single program exists to be attacked and after three hacking attempts, the attacker is blacklisted without any error message. This means the security testing can continue for hour after hour, but as the person doing the testing has been blacklisted, no matter what they do, they will only see the home page. | | Both internal and external penetration tests are hard to design because if an attack is not successful within three attempts, then all future attacks are simply ignored as the user has been blacklisted without any indication that they have been blacklisted. The objective of any penetration test is to follow the same journey as a criminal hacker to discover any vulnerability in any part of the application. This includes an Owner user hacking the application so they can use services that would normally be reserved to be used by a Agent or some other user role. |
|