Custom Query (6 matches)

I would like to bring our codebase framework up-to-date with php 5.3+ standards, specifically with class definitions, public/private method statements, magic functions, etc. Currently it works fine under php5, but I'd like to take the final step so it runs exceptionally on php5 and not at all on php4.

Goals

Identify new features introduced between php 5.0 and 5.3 that will:

• bring tangible benefit for our use (e.g., anything that brings a performance benefit, or improves error handling)
• make the codebase more future proof (e.g., migrating the current mysql_* function calls (which are to be depreciated in v6) with something else, or implement the required aspects of the new Object Model).

The code should run with no errors using 'E_STRICT' and 'E_ALL' error_reporting, and pass all the unit tests (run via codebase/test/run_tests.sh).

Requirements

1. Backwards compatibility with existing sites that use the codebase. This will make implementation of PDO slightly more tricky, but is possible.
2. Don't make modifications that require extensive testing. Currently the codebase is mature and very stable. I hope the changes we make won't' make it unstable.
3. We only implement what we can do in 10-15 hours.

Beau, I'm opening this ticket until we've worked out all the glitches in PEdit.

Here's one: In PEdit.inc.php, this...

id="sc-pedit-<?php echo $name; ?>"

...should be changed to...

id="sc-pedit-field-<?php echo $name; ?>"

...or something similar to prevent the case where $name is "form" or some other conflicting title. Is this id="" used anywhere else?

from the asafaweb scanner – ​https://asafaweb.com/Scan?Url=control.strangecode.com

Secure cookies: Warning

Requested URL: ​https://control.strangecode.com/login.php (POST 1,001 params) | Response URL: ​https://control.strangecode.com/login.php | Page title: Strangecode · Hosting Controls | HTTP status code: 200 (OK) | Response size: 5,262 bytes | Duration: 461 ms Overview Cookies served over HTTPS but not flagged as "secure" may be sent over an insecure connection by the browser. Often this may be a simple request for an asset such as a bitmap file but if it's on the same domain as the cookie is valid for then it will be sent in an insecure fashion. This poses a risk of interception via a man in the middle attack. Result It looks like a cookie is being served over HTTPS without the "secure" flag being set (name : value):

1. _session : ega7g6pldi51uo5novjagjg6n0

Unless the cookie needs to be sent over an insecure connection, the "secure" flag should always be set to ensure it can only be sent with an HTTPS request. More reading C is for cookie, H is for hacker – understanding HTTP only and Secure cookies

Clickjacking: Warning

Requested URL: ​http://control.strangecode.com/ | Response URL: ​https://control.strangecode.com/login.php | Page title: Strangecode · Hosting Controls | HTTP status code: 200 (OK) | Response size: 5,013 bytes | Duration: 532 ms Overview Websites are at risk of a clickjacking attack when they allow content to be embedded within a frame. An attacker may use this risk to invisibly load the target website into their own site and trick users into clicking on links which they never intended to. An "X-Frame-Options" header should be sent by the server to either deny framing of content, only allow it from the same origin or allow it from a trusted URIs. Result It doesn't look like an X-Frame-Options header was returned from the server which means that this website could be at risk of a clickjacking attack. Add a header to explicitly describe the acceptable framing practices (if any) for this site. More reading Clickjack attack – the hidden threat right in front of you