Thursday, 1 January 2015

153. Strictly for WEBSITE Aficionados & Connoisseurs...

VIEWS@10761
I breathe a sigh of relief 'that' season is over for another year. And while I feel there is no such thing  as a Happy New Year, with my other cause related connectives and the determination of thousands towards a fairer, more sensible, and honest world, there seems a foreboding in the air, a sense of potential major shifts during 2015.  

Regardless the search for 'Justice,' although I should have known better, and against all advice of family, friends and those 'in the know,' that we are stuck with who we have become, that I am fighting the business of insiders, this will have to be the year to put this all to bed! There are only so many years left. 

The following, although seemingly way off the charts at this stage of proceedings, I just came across. It is still the most detailed and informed review of the originally built Gopoco.com site. I ended up asking and paying for some 5 independent reviews of the Ottawa Developer's $44,000 effort. Even a high-tech data-base klutz like myself can read through the jargon. I have NO idea why the cut/paste effort shows the yellow highlights. All part of the mystery of computer behaviour I guess.
                                                           Alice ZoëBevan–McGregor
SOFTWARE AUDIT
1.   Overview
This document contains an overview and in–depth analysis of the Gopoco web application as found in the backup-gopoco.com-11-27-2009/public_html/oldsite folder.  This code utilizes the CakePHP framework.
.2.        Structural Overview The code is organized into sub–folders based on a top–level split between the application code, framework code, and third-party code, with the application code represented as follows. Within the controllers, models, and viewsfolders are files (and folders in the case of views) for each major area of the site.
1.              2.1. config — common configuration files, such as database connections and URL routing.
2.              2.2. controllers — the core behavior of the site; logic and processes.
3.              2.3. locale — translation tables for internationalization; unused.
4.              2.4. models — data structure and business logic.
5.              2.5. plugins — extensible plugins; unused.
6.              2.6. tests — unit and functional tests for verifying application behavior; unused.
7.              2.7. tmp — temporary files, such as caches, logs, and user session data.
8.              2.8. vendors — third–party code libraries.
9.              2.9. views — HTML templates used by the controllers to display pages to users.
.2.10. webroot — static files that are served as–is from disk.
.3.        Source Code Management The source code powering the old site was at one time managed under a Revision Control System (RCS) called Subversion. A code “repository” is a centralized copy of the source code that includes the entire history of the project: who modified which file at what time and what the reason for the change was.
.3.1. The URL of the Subversion repository is: http://newton/svn/jansteen
1.              3.1.1. This URL is private; it is not accessible from the internet.
2.              3.1.2. A copy of this repository would be invaluable when attempting to assess development progress and methodology.
2.              4.         Security The CakePHP framework, as mentioned by N-VisionIT, contains code designed and tested to improve security,

1765 Fern Road – Courtenay, BC – V9J 1W7 — Canada
 1 250 897-0780 – alice.mcgregor@me.com
.4.1.      The database model system CakePHP provides is able to armor against a type of attack called an “SQL Injection Attack.” This type of attack, if the code is vulnerable, allows remote users of the system to insert, delete, alter, and examine the data structures usually protected from such anonymous manipulation. In order for CakePHP to protect your application from this attack, developers must utilize the standard database interface, performing queries across the database using published Application Programmer Interfaces (APIs).  Upon examination:
1.              4.1.1. There are 1699 raw (not utilizing CakePHP’s model framework) SELECT statements.
2.              4.1.2. There are 270 raw INSERT statements.
3.              4.1.3. There are 686 raw UPDATE statements.
4.              4.1.4. Of these, a large percentage (31% after a quick search, the true number is likely much higher) utilize unescaped variables, and thus pose a substantial danger to application security and the database.
5.              4.1.5. CakePHP’s built–in function to sanitize input is used a total of 14 times.
.4.2.      Cross–site Request Forgery (XSRF) attacks rely on third–party attackers being able to initiate requests (such as submitting forms) as a regular user, potentially as a specific user who may unwittingly click a malformed link. There are a number of ways to protect against this, and only one has been utilized, and only on a small sub–section of the site. This leaves the rest of the site unprotected.
1.              4.2.1. Recaptcha (a human verification system whereby you enter the words found in a distorted image) is used on the third–party developed forum.
2.              4.2.2. Other techniques, such as the use of a one-time code hidden in the forms, one-time URLs, and CSS–hidden form fields, are not used.
2.              4.3.      Another form of attack, whereby JavaScript is embedded on the page by a malicious user, called a Cross–Site Scripting (XSS) vulnerability or JavaScript injection attack, happens when user input is not properly sanitized before being saved, or is re–displayed on the site without protection. This type of attack can be exploited in two ways: if input to a given page (such as a search page) re–displays user input directly, anyone clicking a malicious link would unwittingly attack the site; and if data saved into the database without sanitization is later displayed by the site, it would allow an attacker to potentially effect all users of the site.

4.3.1. There is evidence of multiple places in the code where form data is redisplayed to the user without adequate escaping to prevent this type of attack.
5. Code Style and Quality
1.              5.1.       There is an internal consistency to the level of indentation and use of brackets to denote blocks of code.
2.              5.2.       However, indentation is comprised of an inconsistent mixture of tabs and spaces.
3.              5.3.      Trailing whitespace has been left in place.
4.              5.4.       There are multiple PHP scripts that contain no closing tag.

1765 Fern Road – Courtenay, BC – V9J 1W7 — Canada
 1 250 897-0780 – alice.mcgregor@me.com
1.              5.5.       Of the 7,310 lines of code, excluding blank lines, only 1,727 of those lines contain descriptive comments. Additionally, there are 151 block comments.  (A significant amount of this code is boilerplate.)
2.              5.6.      Based on the sloccount source code analysis tool, this project is estimated to have had a schedule of 7.71 months.
3.              5.7.       There are obvious holes in the code; it feels incomplete. There are several controllers not bound to the application by the routing configuration, and some only contain part of the required functionality.
4.              5.8.       Another static analysis tool (Pixy) reports that for a given request there are up to 3,013 cross–file inclusions, requiring the PHP scripting language to process large quantities of unused code.

6.   Initial Findings The following are my initial findings:
1.              6.1.      The codebase is incomplete, not fulfilling the goals of the minimal Requirements Document provided and agreed to.
2.              6.2.      The codebase is insecure due to fundamental decisions to not use the tools provided by the framework.
3.              6.3.      The codebase is inefficient.
4.              6.4.      There was an organized development process, involving the Subversion revision management system and framework– preferred file/directory structure, though I can not comment on the development process outside of revision control.
5.              6.5.      The project scope was too wide.
6.              6.6.      I estimate the cost of development as excessive for the quality and quantity of work completed. For a project such as this I would likely bill no more than $30,000 CDN.  Bids would likely range from $25,000 to $45,000.
7.              6.7.      The use of MySQL and PHP is not unusual, though potentially the site would be easier and faster to develop using Python, a language that has now been existent for 20 years, with less work needed to secure the application.
8.              6.8.      No attempt was made to utilize the framework’s built–in internationalization (translation) capability despite translation being a fundamental goal for the project.
9.              6.9.      With a lack of unit or functional testing, there is no way to prove the application performs as designed.

6.10. It is imperative that a copy of the Subversion be made available for further analysis and timeline investigation.
7.   Document History
1.              7.1.       Initial Revision    Thursday, April 7, 2011   No comments.
2.              7.2.       Proofed Revision
3.               Thursday, April 7, 2011
4.               Grammatical and ease–of–reading changes.
Addition of Document History section.
Minor reordering of items in §5.






No comments:

Post a Comment

Post a Comment