Gregory D. Evans / LIGATT XSS #4

Yet another Cross-site Scripting (XSS) vulnerability was found and disclosed on LIGATT's web site. Why is this interesting or news-worthy?

In short, XSS shows that a developer did not properly sanitize user supplied input. For the most part, any input validation vulnerability (e.g., XSS, SQLi, RFI, LFI) is based on sanitizing dangerous characters. Fixing one XSS vulnerability should in turn fix every XSS vulnerability. Sanitize input to one field, apply the same protection to every field, problem usually solved.

On May 15, 2010, the first XSS was found on their site, and apparently fixed within a couple days. While the fix was fast, LIGATT chose not to make any public announcement about the issue. They also apparently chose not to apply the same fix to any other site they run. Four days later, their nationalcybersecurity.com web site was found vulnerable to XSS. If that wasn't a good lesson, the same LIGATT site was found vulnerable to XSS a second time six days later. A couple days after that, LIGATT's untraceablemail.net site was also found vulnerable to XSS.

This pattern demonstrates that LIGATT has no regard for their own security, and likely does not have the technical proficiency to properly defend their web sites from XSS attacks. Since many of their services are based on customer accounts, XSS is particularly important to the sites as authentication credentials would be at risk from a serious XSS attack.

Earlier today, on June 7, yet another XSS vulnerability was found in ligattsecurity.com. The initial tweet demonstrated the standard popup, and subsequent tweets demonstrated the injection of third-party content into LIGATT's web site. The question remains, how can LIGATT promise to offer any level of security when they can't protect their own sites from the most basic of XSS attacks over 22 days?


main page ATTRITION feedback