A guest portal is a web application that collects personal data, sits on the same infrastructure as the systems running your business, and is used by hundreds of strangers a week. Venues treat it as a network feature. Testers treat it as an application, and that difference in perspective explains most of the findings, from guest records readable by other guests through to a route from the car park into the back office.
Where the portal sits on the network
The first question is what the guest network can reach, and the answer is often more than intended. Portals frequently run on hardware that also serves the corporate network, with separation enforced by VLAN configuration nobody has verified since installation. From a guest session a tester will look for the wireless controller’s management interface, the property management system, door access controllers and the till network. Client isolation is the other common gap: with it disabled, one guest can see and attack another guest’s laptop, which in a conference venue means one attendee can reach the machine of everyone else in the room.
Authentication that only pretends to authenticate
Room number and surname is a guessable pair, and voucher codes are often sequential. Where access is granted by MAC address after payment, a tester watches the air for an authorised address and clones it, which takes minutes and costs nothing. DNS is the other classic route: many portals allow DNS queries before payment so the captive portal can work, and a tunnel over DNS turns that into unrestricted access. None of this is sophisticated. It is the kind of thing a bored guest with a laptop finds, which is why it tends to be reported by customers rather than by staff.
“In venue work the finding that worries the client most is never the free internet. It is that the portal database holds names, room numbers, email addresses and arrival dates for everyone who has stayed there since it was installed, with no retention policy and a default administrator password. That is a data protection problem before it is a network one.”
William Fieldhouse, Director, Aardwolf Security Ltd
The data the portal collects
Treat the portal as a system processing personal data, because it is. Email addresses gathered at sign-in are frequently used for marketing later, and the rules under PECR, which the ICO enforces, require consent that is freely given rather than a condition of getting online. Check how long records are kept, who can export them, and whether the supplier who installed the system still holds administrative access. Ask where the data physically sits, since many portals are cloud hosted by the vendor with a shared administrative interface across multiple venues.
Testing it as one system
Cover the radio, the network and the application in a single engagement, because the interesting findings cross all three. A Wi-Fi penetration testlooks at the wireless layer and the segmentation behind it, while web application security testing covers the portal itself, including authentication, injection and the administrative interface that is often reachable from the guest network. Splitting the work between two suppliers usually means each stops at the boundary where the other should have started.
Frequently asked questions about guest wireless
These questions come up whenever a venue reviews its network after a complaint or an audit.
Should guest wireless be on a separate internet connection?
It is the cleanest answer where the cost is acceptable, because physical separation removes the segmentation argument entirely. Where a single connection is shared, insist on separate VLANs, client isolation and a firewall rule set you can read.
Is a shared password acceptable for a small venue?
For internet-only access with proper isolation, it is workable. The password stops being meaningful the moment it is printed on a card, so the isolation is doing all the work and should be tested rather than assumed.
