Slashdot Mirror

Or more relevantly, I think this is what the original poster was referring to:
https://www.whitehatsec.com/bl...

Here are some examples of PHP doing mind boggling things with md5 and sha1 hashes.

https://3v4l.org/tT4l8

Overall language issues PHP is number 6 in this list...
http://www.aabri.com/manuscrip...
In terms of web apps, PHP looks pretty damn good by comparison:
http://info.whitehatsec.com/rs...

WhiteHat Security says its "Aviator" browser protects your privacy. "We protect your privacy by launching directly into private browsing mode, blocking ads and other tracking mechanisms, disallowing third-party cookies, and cleaning your system when you exit." Anyone know anything about these guys?

>

To my mind, provided that the algorithm doing the conversion is appropriately protected, pseudonymisation may be one good method of reducing the risk associated with the processing of personal data, protecting it in the event for a data breach, and thus be a form of security measure, but is unlikely to stop the data from being capable of identifying the individual, in the hands of the party carrying out the pseudonymisation.

With all respect, your mind and common sense are superseded by better minds:

Robust De-anonymization of Large Sparse Datasets

Our techniques are robust to perturbation in the data and tolerate some mistakes in the adversary’s background knowledge.
We apply our de-anonymization methodology to the Netflix Prize dataset, which contains anonymous movie ratings of 500,000 subscribers of Netflix, the world’s largest online movie rental service. We demonstrate that an adversary who knows only a little bit about an individual subscriber can easily identify this subscriber’s record in the dataset. Using the Internet Movie Database as the source of background knowledge, we successfully identified the Netflix records of known users, uncovering their apparent political preferences and other potentially sensitive information

Deanonymizing Mobility Traces: Using Social Networks as a Side-Channel

Location-based services, which employ data from smartphones, vehicles, etc., are growing in popularity. To reduce the threat that shared location data poses to a user’s privacy, some services anonymize or obfuscate this data. In this paper, we show these methods can be effectively defeated: a set of location traces can be deanonymized given an easily obtained social network graph.

I know... series (scroll to the bottom of the page)

A LOT About Your Web Browser and Computer
The Country, Town, and City You Are Connecting From (IP Geolocation)
What Websites You Are Logged-In To (Login-Detection via CSRF)
I Know Your Name, and Probably a Whole Lot More (Deanonymization via Likejacking, Followjacking, etc.)
Who You Work For
Your [Corporate] Email Address, and more

De-anonymizing social networks

Network de-anonymization task is of multifold significance, with user profile enrichment as one of its most promising applications. After the deanonymization and alignment, we can aggregate and enrich user profile information from different online networking services and make the bundled profiles available for end-users as well as third-party applications.

Actually you know what? lmgtfy

I've had the privilege of meeting Jeremiah Grossman at a security conference. I'd recommend reading several of his white papers and then decide if you want to call his company up. I doubt they are cheap, but the best rarely is.

http://www.whitehatsec.com/home/index.html

If you constantly find flaws by hiring pentest firms, you are in the wrong stage. You need to get Secure SDLC built into your development and actually try to catch these flaws in the design phase.

That is great in theory, and might be true in the future, but you are missing the reality of the software development industry as it stands today.

1) Universities are not teaching software engineers about application security.

2) Most development organizations do not have leadership that understand the complexities and processes needed for secure software engineering.

3) Network Security training organizations like SANS teach courses around application security that barely teaches developers the skills needed to write secure applications. They still approach appSec from an operations point of view - where just like WAF deployment, you are too late or doing to little.

To really crack the AppSec nut, I recommend you approach this problem from several angles.

1) Start by (continuously) training your developers regarding application security. There are few firms that really do this well in a developer-centric way. Aspect Security ( http://www.aspectsecurity.com/ ) and Whitehat Security ( http://www.whitehatsec.com/ ) are 2 of the leaders in this field.

2) Begin building in-house application security pentest teams - this is a very different skill set than netSec pen testers. (You are right, you cannot just keep hiring pentest firms for the long haul)

3) Next do a risk assessment and catalog your applications current risk posture. Management appSec training is needed during this phase, as well.
4) Bring in a appSec pentest firm to assess your highest risk applications. Keep track of these results carefully so that fixes from developers can be tracked over time to verify that you are really reducing the applications risk posture over time.

Achieving application security excellence is a difficult process. And 3rd party application security training and application security pentesting (assessment) is critical on the path to success.

"If you want to be 100% compliant with RFC 2068, a document defining the standard behavior of the world wide web, you must include TRACE." noted Lex Arquette, Chief Technology Officer of WhiteHat. http://www.whitehatsec.com/press_releases/WH-PR-20 030120.txt

Strange... RFC 2068 seems to be obsoleted by RFC 2616 since June 1999... :-)

A few links worth interest.
www.cgisecurity.com
www.whitehatsec.com