This portal is a dumb idea, but most developers know you don’t let on when a hack is attempted and you detect it. It’s common to return a “success” message in hopes the “hacker” stops trying and moves on. Meanwhile, you log the attempt (and don’t actually cancel a voter registration).
Though, I don’t have high hopes the state actually built a secure site here.
“Incomplete paper and online applications will not be accepted,” Evans said in the statement. (Parker’s [demonstration] cancellation request would have lacked a driver’s license number.) The Secretary of State’s Office did not respond to individual questions about what testing the portal underwent before launch, the system’s security procedures, what happened to Parker’s cancellation request…
Yeah, that tells us we just don’t know if this was a problem after all. Evans’s statement basically claims it wasn’t a vulnerability. If that’s correct, then the worst thing might be if someone’s browser tripped on the validation JS and allowed them down a blind alley execution path. If the claim is correct and if the page’s JS never shits the bed, then in that case the only negative outcome would be someone dicking with the in-browser source could lead themselves down the blind alley, in which case who cares. The only terrible outcome seems like it would be if the claim is incorrect–i.e. if an incomplete application submission would be processed, thus allowing exploit.
Short of an internal audit, there’s no smoking gun here.
This portal is a dumb idea, but most developers know you don’t let on when a hack is attempted and you detect it. It’s common to return a “success” message in hopes the “hacker” stops trying and moves on. Meanwhile, you log the attempt (and don’t actually cancel a voter registration).
Though, I don’t have high hopes the state actually built a secure site here.
Yeah, that tells us we just don’t know if this was a problem after all. Evans’s statement basically claims it wasn’t a vulnerability. If that’s correct, then the worst thing might be if someone’s browser tripped on the validation JS and allowed them down a blind alley execution path. If the claim is correct and if the page’s JS never shits the bed, then in that case the only negative outcome would be someone dicking with the in-browser source could lead themselves down the blind alley, in which case who cares. The only terrible outcome seems like it would be if the claim is incorrect–i.e. if an incomplete application submission would be processed, thus allowing exploit.
Short of an internal audit, there’s no smoking gun here.
It’s still grossly negligent from a security perspective.