BeEF – Browser Exploitation Framework

BeEF is a browser exploitation framework.

BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.

Amid growing concerns about web-borne attacks against clients, including mobile clients, BeEF allows the professional penetration tester to assess the actual security posture of a target environment by using client-side attack vectors. Unlike other security frameworks, BeEF looks past the hardened network perimeter and client system, and examines exploitability within the context of the one open door: the web browser. BeEF will hook one or more web browsers and use them as beachheads for launching directed command modules and further attacks against the system from within the browser context.

PHP limit on maximum form fields

We had an interesting issue to debug at work today.  One of the screens in our application features a form with a whole lot of checkboxes.  It’s in the access control module, where the administrator of the system can manage user permissions for each module of the system.  Here’s the screenshot just to give you an idea.

This is not the pretties user interface (yet), but it sort of works.  Every module can be expanded or collapsed, and inside each modules all checkboxes can be checked and unchecked easily.

The problem that we had wasn’t user interface related.  It was something else.  The number of modules and permission checkboxes varies from system to system.  This is based on each particular system setup.  Now, on some of these systems, it was reported that some permissions are not being saved.

The problem is not new, but it was slowly escalating with more and more clients reporting it.  So, today we dived into it and found the cause of it.   Since PHP 5.3.9 there is a new runtime configuration setting: max_input_vars, with default value of 1.000:

max_input_varsinteger

How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

So, on the systems, where the form contains more than a thousand checkboxes, PHP was only bringing in the first thousand and skipping the rest, causing not all permissions being saved properly.

Increasing the value in runtime configuration is one way to solve it.  But since we have a rather dynamic system and don’t always control the runtime configuration (client hosting), we opted for a different solution.  As per this StackOverflow thread, it’s a much more future-proof solution to combine the values into a single field.  Either simple concatenate, or JSON-encode the values on form submit, and send them all as a single field value.  Then just split or JSON-decode on the server before processing and you are done.

P.S.: The extra bit that made the troubleshooting so much more difficult was that for some reason we were not seeing the PHP warning in logs.

 

On Semantic Versioning

First of all, you should know that versioning is important.  Even the worst versioning practices provide more value than no versioning at all.  At work, we are big fans of the Semantic Versioning, and we use it for all our projects, plugins, and libraries.  And I think, you should do too.

In general, Semantic Versioning works great for us.  But there were a few bumps recently, with more and more libraries dropping support for PHP 5.6 and requiring PHP 7.  I can’t blame them – after all PHP 5.6 has reached its end of life quite a while ago.

It’s not what the maintainers do, but how they do it that I have an issue with.  I’ve been thinking about writing a blog post on the subject for a few month now.  Never got to it.  And yesterday I came across this blog post by Paul Jones, which is so much better than whatever I was about to say.  Paul explains the problem in detail and suggests the “System” addendum to Semantic Versioning:

I opine that requiring a change in the public environment into which a package is installed is just as major an incompatibility as introducing a breaking change to the public API of the package. To cover that case, I offer the following as a draft addendum to the SemVer spec:

  • If the package consumer has to change a publicly-available system resource to upgrade a package, then the package upgrade is not backwards-compatible with the existing system, and the package SHOULD receive a major version bump.

Using “SHOULD” makes this rule somewhat less strict than the MUST of a major version bump when changing the package API.

Coming back to PHP 5.6 vs PHP 7, that would suggest that maintainers who drop support for PHP 5.6 SHOULD bump up the MAJOR release of the library.   And I wholeheartedly agree with that!

P.S.: For those of you who don’t or can’t use Semantic Versioning for whatever reason, checkout Paul’s blog post on Semantic Versioning vs. Romantic Versioning.

spf13-vim : The Ultimate Vim Distribution

spf13-vim is an amazing Vim distribution with cross-platform configuration and a large bundle of plugins, aimed at programmers in all sorts of languages.  Those of you just starting with Vim, or using a very basic configuration, give this one a spin.  And for the rest of us, ancient farts with 10+ year old configurations, this distribution provides plenty of inspiration for plugins and configuration options to try and play with.

I’ve seen a variety of Vim distributions and bundles over the years, but nothing came close to this amazing setup.  Very well done!

Every Programmer Should Know

Every Programmer Should Know” is a collection of subjects and resources that every programmer should know.  It is not specific to any technology stack, and it’s rich enough to offer something to programmer of any level or experience.

While the whole list is great, I’ll single out this Big O Cheatsheet:

Multiple Perspectives On Technical Problems and Solutions

Multiple Perspectives On Technical Problems and Solutions” is an interesting take on engineering in general and software architecture in particular.  It starts off with:

Fundamental: engineering decision-making is a socially constructed activity

[…]

In other words, engineering (as an activity) does not have “correct” solutions to problems. As an aside, if you’re looking for correct solutions to problems, I’d suggest that you go work in a different field (like mathematics); engineering will likely frustrate you.

It then goes into dialogues and discussions, architecture review meetings, and provides a few pointers on how to get the best of those.

Angular vs. React vs. Vue: A 2017 comparison

Angular vs. React vs. Vue: A 2017 comparison” is a very lengthy and detailed comparison of the top three most popular JavaScript frameworks: Angular, React and Vue.  There are also lots of links and references for further reading, but even if you don’t leave the article, chances are you’ll have a pretty good idea of which framework suits you best.  For me, it looks like it’s Vue.

And as a side note, this quote made me smile:

The dirty little secret is that most “modern JavaScript development” is nothing to do with actually building websites — it’s building packages that can be used by people who build libraries that can be used by people who build frameworks that people who write tutorials and teach courses can teach.I’m not sure anyone is actually building anything for actual users to interact with.