Entries with the tag “security”

I love using Eloquent’s sole() method in Laravel. It throws an exception if the result set is ever more than 1. It means you should only have a sole record. This is usually what I want. I’ve migrated away from firstOrFail() unless I legitimately want the first of a matching set.

But I just found another reason to love using the sole method - it helps add a layer of protection against SQL injection. Let’s find out how.

You’ve got Laravel throttling set up on authentication, password reset and other sensitive endpoints. But, how do you know this is actually working to stop people? Or what if you either want to admonish bad users or proactively reach out with support to help them? Perhaps you might want to log your throttled attempts. It’s pretty easy.

There are a number of tools and packages that help you manage your users and their associated password reset flows available. The Laravel docs also describe a way that you can reset your password in your own controller. Depending on the use case of the application, I end up having to use code like this in some applications when other packages won’t work as drop-ins. But, can we make this example a little better, more secure, easier to read or a better UX? I think so. Let’s go.

I can’t say how much I love Github actions. It really felt like a game-changer for me. But I always had some concerns about security. How do we stop 3rd party actions from accessing stealing our code?

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.

Laravel is a great framework that is pretty secure by default. However, configuration mistakes or coding errors can still leave your app open for attack. Where do you go for help?

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.)

When you’re creating cookies on your server side application, it’s good security practice to flag the cookie as HTTP Only. This way, it instructs the browser that it should sandbox this cookie from the client side scripts. It still will send it between client and server on each subsequent request, but javascript can’t access it directly.

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:

tldr; Remember to use rel="noopener" on target="_blank" links where you do not control the destination.

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 default configuration 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.

Out of some sheer boredom, I started looking at the top 25 used passwords (from articles here and here).

In part 1, I discussed the various arguments I run into about wanting to be overly security conscious with our sites in regard to third party javascript. In this entry, we’ll run through a few scenarios.

I have the argument a lot with product managers about allowing custom HTML and Javascript into our projects. I don’t want to do it. I want to only put in predefined, sanitized information. But more about my reasons after this… let’s look at the arguments I get first…

I was doing some code challenge review for an open web developer position I have for my team, and I came across one piece of code that made me smile.

There are two areas where user input should be filtered: on display and on storage. Luckily, Zend Framework provides tools for this…

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:

So, if you’re not familiar with CSRF, check out this blog post about AJAX Security. Some of the steps talking about Cross Site Request Forgeries will help you understand the problem.

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:

Just saw this really cool example get submitted on one of my websites testing for CSRF:

I thought I’d take some time to look at the 3 main ways that I’ve handled forgotten passwords on my websites, why I did them that way, and if there was anything wrong.

I remember a while ago hearing about a few theoretical collisions of the MD5 algorithm, but I thought nothing of them. Now, as more information emerges, Microsoft is issuing advisories, and people are proving more and more collisions with example code, and even md5 is out of vista, I figure its time to remind everyone not to use MD5.

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:

JSTool was a trial run of combining many different scripts from the open source community into a security and auditing script.

PHP stores its session information into flat files unencrypted by default.

So much of my time is spent worrying over the src or href tags on images and links - that I sometimes forget about the other attributes.

In regards to the Data in URL scheme (RFC here), I’ve found an interesting issue with the way firefox handles it which could lead to some XSS I think.

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:

The “security guys” have been talking about the problems with FireFox’s password manager and I got curious. It turns out that javascript can access saved passwords in your password manager simply by creating a login form and capturing the input field’s contents.

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:

Round 2, and the final round, is complete! The previous article here talked about my initial findings. Well, I was able to try some proofs of concepts on my javascript finding, and I put together our top level recommendations for (”the triangle”). Let’s see:

(“the triangle”) wants to keep implementing more and more AJAX based systems - but no one ever took time to research into the security issues with this.