Design, photography and ramblings

Month: May 2020

The pitfalls of working with a framework like Laravel (v7.x)

Laravel is great as a development framework. It handles lots of things for me that I have no interest or time to manually code such as cleaning my SQL queries or providing methods to talk to my databases. But with all of this framework magic comes some headaches; documentation.

When trying to find properties that a method inherits, such as the ‘updateOrCreate’ method, how do you know that the method has an $incrementing property that might need to be set for your use-case? Currently in the Laravel API search, properties are not searchable. The problem is with PHP documentation generators in general that do not provide property searching, mainly because they do not catalogue inherited method properties. This makes it difficult to learn Laravel because there is no easy place to find/search method properties, either through an IDE such as VS Code or the Laravel API docs.

A lesson in Zoom meeting passwords and Zoom bombers (if you are setting up Zoom meetings you need to know this)

Meeting passwords:
First let me say that a number of links to Zoom meetings on most websites DO NOT require a password to get into the meeting (whether that makes the meeting vulnerable to Zoom bombing is separate issue). Even though a password was set for the meeting, the key to get into the meeting was provided in the link/URL address to the meeting. Let me explain using the following Zoom meeting URL as an example.

https://zoom.us/j/668360261?pwd=U1R6djFFVTNIenM1SWJVSTdCY0JTdz09

====== A quick breakdown of the web address ====
The ‘?’ in the uniform resource locator (URL) begins the ‘query string’. A query string is the part of a URL which assigns values to specified parameters. The less techie terms it means, “We are about to send some information in the website (zoom.us in this case) to provide this website with some special information about the user accessing the website or maybe their access privileges for example.” Following the ‘? ‘are name=value pairs. In this case we only have one pair ‘pwd=U1R6djFFVTNIenM1SWJVSTdCY0JTdz09’ where ‘pwd’ is the name and ‘U1R6djFFVTNIenM1SWJVSTdCY0JTdz09’ is the value of ‘pwd’. The value of ‘pwd’ is a backdoor to getting into the meeting, and tells Zoom “It’s okay, to let this person into the meeting without them typing the password”. The value of pwd is set to a long random string to make it impossible for others to guess. In other words, if you wanted to give your friends a backdoor into this Zoom meeting without entering a password then you could send them this link, and then send everyone else to the front-door, being ‘https://zoom.us/j/668360261‘. Others would never be able to guess the pwd part of the URL (and neither would any automated scripts) and would be forced to login manually.

Extended learning (not related to Zoom):
Online surveys for example use URLs that look like qualtrics.com?respondentId=pgale&surveyVersion=1, where ‘respondentId=pgale’ may tell the website that the response for this survey is being enter by respondent ‘pgale’ and an additional ‘surveyVersion=1’ may tell the website to use version 1 of the survey (the ‘&’ in a URL simply indicated multiple ‘query string’ values or properties being sent within the website request; clicking a link to a website is making a request to that website). It is up to the programmers of the website to define the meaning and uses of these values within the website context. Being a web programmer you learn to guess what the query string values of a web address are and what the website is trying to do with that information (you can play around with this by changing values within a query string and see what happens when you change them and make the request).
=========================================

Now that the anatomy of the URL ‘query string’ is understood (hopefully) we will return to the Zoom URL for our meeting. Even though our Zoom meeting IS password protected, Zoom gave us a URL that circumvents that password prompt and provides all users of this URL a backdoor to the meeting. Everyone is VIP.

If you want to force your Zoom meeting attendees to enter a password in order to access the meeting, the URL to the Zoom meeting should NOT include the ‘pwd’ (you guessed it, ‘password’) query string value.

Now if we try to simply access the Zoom meeting without the backdoor password using the following link:
https://zoom.us/j/668360261
…we are forced to manually enter the password.

We could try accessing https://zoom.us/j/668360261?pwd=123 and it would still take us to the meeting, however we would need to enter the password since the backdoor key to the meeting is not correct.

Zoom bombing:
I would guess that 99.9% of Zoom bombing is initiated by a ‘bomber’ running automated scripts that crawl website content to extract Zoom addresses that include the ‘pwd’ query string (I know because I could write such scripts). The other 0.1% are just bored people playing pranks. Anyway, the automated scripts are not going to care about Zoom addresses without the pwd query string because the pwd query string most likely provides guaranteed backdoor access to the meeting. If a bomber needs to manually enter passwords to access a meeting then that slows them down in bombing the maximum number of meetings. They are in it for the automation challenge. So to stop tempting those bombers from attending your meetings do not include the ‘pwd’ query string in the meeting URLs on website posts or other media. It is still possible for bombers to parse the password from a meeting event page on a website, however they would still need to manually enter the password to access the meeting. Best practices are to simply disable attendee interaction for presentations or to only allow chat messages to the meeting hosts to relay to the presenter. If you are blocking attendee interactions within your presentations then it really doesn’t matter if you provide the backdoor URL to the meeting.

Enjoy your ‘Zooming’. I have Zoom-fatigue.