If Google gives free access to their web traffic tool called Google Analytics, why would you need anything else? Why would you care? Let’s briefly talk about why privacy matters and what you can do instead.
When given a choice of methods and ways to do something, it might not be clear which way is the best. As programmers, we tend to pick the easiest, then. However, the easiest can have security implications. Let me illustrate why we should use more stringent controls in a Laravel project.
Open source software is wonderful for many reasons. One of the best is we can see and inspect the software for vulnerabilities. But, far too many people actually do this. Let me demonstrate, using a Laravel package, how this lack of review might backfire and cause you grief.
One of the lesser known pieces of functionality from Composer is the ability to create a project from skeleton/scaffolding. This ability allows you to create a project structure, directory, files and requirements based on the suggested setup from the project maintainer. A common installation mechanism of Laravel uses this functionality. (Even I use it to save time and set up my own custom configuration for new project skeletons.)
The other day I was at a coffee shop and I looked around at all the Mac’s open. It used to be that you’d see people writing manuscripts at coffee houses. Surprisingly, this place held a lot of programmers. I suddenly thought of something interesting:
It’s hard to come up with a title for this - but - basically I found some rogue code the other day that I thought was pretty interesting. I was fixing a “hacked” website when I came across the source of the symptoms of the hack. One file had the following code in it:
One thing I like about Laravel is the amount of built-in functionality that is available. But when this functionality is left in default configuration (much like many defaultconfiguration items getting hacked), there can be consequences.
Today I was faced with an interesting quandary about whether I should write the code to exploit an application vulnerability in our software at work. This vulnerability is not necessarily a “security” one, but more-so a known-risk: it was theorized that someone with enough knowledge could bypass a mechanism in our software.
Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.
There are a number of performance arguments about combining assets to reduce HTTP requests and speed up your site. I agree! However, I do have to say that there is such a thing as overkill - to the detriment of speed and security…
I came up with a great topic to write this blog entry about: filters and validators. Then, I got to thinking - maybe I can get more feedback from other programmers I know. I decided to send a note out to a few of my buddies and see what they thought as well.
The last time someone brought up authorizing certain actions by IP address - or I should say, limiting the amount of actions that can happen by one IP address. I brushed that off without a second thought. It didn’t occur to me until later that the original owner of that idea may not have known all the reasons why I know this isn’t a good idea. So here’s a quick rundown:
For whatever reason, I can never remember the exact coding of MCrypt. And maybe that is a good thing - so I stop doing so much code duplication and start using a class I wrote. For this reason, I’ll save you the same frustrations and share how I do my encryption.
Do you use Git to manage your repository? If so, do you use it to check out code onto the server as well? If you do, you really should restrict access to your .git directory if it’s in your public root. (If you’re using things like Zend Framework, chances are your root directory is not your public directory, so you have less to worry about.)
A friend of mine posed a question: Do you know of any good PHP based vulnerability scanners? I told him I did not (add any in the comments, if you know! :) ) - but it wouldn’t be that hard to build one. He asked me to give him a code example, so here goes:
After many times of coding relatively the same thing, it becomes prudent to have a standard library for certain sets of processes. Of course - that is why there are things like frameworks! At any rate, one of the biggest things I run into is password complexity. Each website has its own requirement for the security they want to implement. So, let’s talk about the requirements and then look at the code:
As you probably remember, I have lots of interest in phishing techniques (I talked about one here, and preventing them here). I’ve noticed a new trend: a dual stage login form with a custom picture or passphrase. Users are to gain trust in the login page because their custom configured option is displayed. The more I started thinking about this, however, I kept seeing an issue - this still can be easily phished!
A big issue with PHP security had been the developers creating a php info page and not removing it from a production site. As you may know, phpinfo() will dump a ton of useful information (for the developer - as well as the cracker) to the screen:
I don’t want to admit it - but I messed up. I didn’t patch wordpress - and I was a victim of one of the released wp exploits. How could you let this happen? you ask. Well, I was lazy. But let this be a lesson to ya - don’t forget - otherwise its a LOT harder to clean it up (it took me roughly 4 hours to fix which included 2 hours of ignoring my friend on the phone…)
So after searching the Internet for some cross domain AJAX stuff, I noticed two interesting articles. The first was the specifics of writing these queries (located here). Then, the next gave a breakdown of how this might be useful in a mash-up collaborative sense (here).
An interesting idea that a colleague told me about was a ‘security trigger’ in any application that has a SQL type storage engine. The trick is to make sure that your admin account is not ID #1 and that your administrative username isn’t one of the most common ones:
So many phishing attempts lately are just purely pathetic - easy to guess and figure out, mis spelling and grammar issues and just poorly fashioned websites. Although these will work on the novice web surfer, can a clever criminal actually create a phishing site/scenario that can trap the experienced members in your IT department?
The following is the result of a research project I had done about phishing. Its some best practices and suggestions based upon information from leading security professionals such as white hat security, McAfee, etc. A combination of e-mail security, authentication methods and corporate identity standards are among the suggestions… Here are the top solutions and methods of securing against Phishing: