-Поиск по дневнику

Поиск сообщений в rss_thedaily_wtf

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 06.04.2008
Записей:
Комментариев:
Написано: 0


Paying Cache for Insurance

Вторник, 16 Июня 2015 г. 13:30 + в цитатник

If you asked the web developers at XYZ Insurance, a mere network engineer like Billy had no business snooping around in their code. He probably doesnt even know what HTML stands for, theyd sneer, and they kept sneering until a routine change to fulfill an audit requirement brought their internal website grinding to a halt.


Green Gecko gobeirne
This article is actually about a health insurance company, but they dont generally have cute CGI mascots

It was a security audit, and Billy had already seen the audit report. It was produced by a contractor at the request of corporate. There were two main problems with the internal site, and both were serious enough that Management told the developers to drop everything and fix them:

  1. The main insurance policy application allowed caching of HTTPS responses, which meant sensitive information might survive a browser session in the local cache, potentially making it available to unauthorized users
  2. The login / forgot password / change password forms allowed auto-completion, again potentially exposing credentials to those unworthy thereof

Now, Billy was no web developer, but he understood the proposed solutions: set a Cache-control: no-store header on all pages with sensitive information (policy details, social security numbers, etc.), and add autocomplete="off" to the

tags that contained password fields. Simple. So simple, that when insurance agents started calling the support line complaining of empty white screens and sluggish responses, Billys team assumed their infrastructure must be to blame.

Definitely no network issues, Billy one of his technicians reported.

And the load balancers? Billy asked.

An awful lot of throughput, were at like 15-mbit, steady. But there doesnt seem to be anything wrong with them.

Its been four days! Billy put his face in his hands. Were gonna have to get Cisco on the phone.

The technician shuddered. Thats always fun. And expensive. Are you sure theres nothing left to check?

Billy thought long and hard. Well… I guess weve assumed the developers already debugged their end, but… He opened up a browser and its debugger and plunged into the forbidden world of web development. The first thing he noticed was a Cache-control: no-store header on a page containing static content. A few more requests revealed the same. Did the developers really disable caching for every response in the application, forcing even mundane images, stylesheets, and scripts to be served over again on every round-trip? Turns out, thats exactly what the developers had done. Billy escalated to Management, and the fix was soon rolled out.

All was well for a few days- the weekend, really- but bright and early on Monday, another of Billys teammates pointed out that his browser was still offering to auto-fill his password. Billy started snooping around again and found that, while caching was disabled on the sites login form, autocomplete was not. On a hunch, Billy logged into a test account and opened a policy.

The page is still caching!

No way, Billys teammate came over to look at the developer console. Do you think they could just be messing with us?

Anythings possible. Wed better get some screenshots of the sensitive data still in cache before we raise this with Management.

Billys intuition turned out to be right; Management was skeptical that the network engineers were turning up so many bugs that the developers had missed, and initially dismissed the complaints. The proof was in the screenshots, however, and Management arranged a meeting to circle the wagons and cut the churn.

After Billy raised his points, the dev manager rolled his eyes. We were given two instructions, the dev manager explained: roll-back the disabled caching, and secure the login form. So thats what we did. Im not sure I see the problem.

At first, Billy didnt know how to respond. He took his copy of the auditors report, circled the two key recommendations in red, and passed it over to the dev manager.

If youll take a look at the report, youll see there are another two instructions. Would you please ask the developers to do those next?

The dev manager huffed. Fine.

The next day, caching was disabled site-wide again.

[Advertisement] Use NuGet or npm? Check out ProGet, the easy-to-use package repository that lets you host and manage your own personal or enterprise-wide NuGet feeds and npm repositories. It's got an impressively-featured free edition, too!

http://thedailywtf.com/articles/paying-cache-for-insurance

Метки:  

 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку