Как только пользователь войдет в систему, я постараюсь избегать любых видов клиентских скриптов, за исключением случаев, когда это АБСОЛЮТНО необходимо. Вот рекомендации, которые я бы порекомендовал для веб-работы относительно финансовых услуг онлайн:
1) Отправьте ВСЕ активы пользователю через HTTPS из того же домена. Хотя это медленнее и наиболее затратно для полосы пропускания, оно также более безопасно, поскольку вы напрямую управляете всеми активами. Под всеми активами я имею в виду все активы, включая изображения, поскольку манипуляции с изображениями, содержащими текстовое содержимое, могут использоваться для отправки ложных инструкций до попытки фишинга. В связи с этим я бы не использовал CDN для хранения ваших активов, потому что это не то место, которым вы владеете, поэтому у вас меньше возможностей контролировать хранимые данные для подделки.
2) НЕ используйте AJAX или что-либо еще с объектом XMLHttpRequest. Точка асинхронного взаимодействия заключается в передаче информации между точками за пределами перезагрузки страницы. Это здорово для удобства использования, но полностью нарушает безопасность. Так как он выполняется на стороне клиента, скомпрометированный код также может быть использован для победы над законным шифрованием SSL путем передачи информации от пользователя ненадежной третьей стороне после того, как информация расшифрована на стороне пользователя. При работе с покупками, PII или финансовыми данными ВСЕГДА следите за тем, чтобы каждая информационная транзакция пользователя вынуждала перезагрузить страницу или новую страницу.
3) Избегайте использования каких-либо сценариев на стороне клиента. Средства не используют ActiveX, Flash или даже Acrobat вообще. 95% всех обнаруженных уязвимостей безопасности связаны со сценариями на стороне клиента, а 70% этих атак направлены на повреждение памяти программного обеспечения для обработки. Хотя JavaScript обычно не известен как переполнение буфера, я все же рекомендую использовать его как можно меньше, чтобы манипулировать только DOM.
4) Никогда не передавайте анонимную функцию в качестве аргумента функции или метода в JavaScript. Это не то, что обычно происходит, но в случае некоторых встроенных методов это может позволить пробелу через интерпретатор JavaScript для программного обеспечения обработки, которое затем может быть вектором атаки для вставки кода, необходимого для переполнения буфера.
5) Не используйте событие onsubmit, чтобы прикрепить выполнение скрипта к отправке данных формы. Нарушение исполняемого кода или добавление дополнительного вредоносного кода может создать точку, в которой можно включить функцию XMLHttpRequest для анонимного передачи данных формы ненадежной третьей стороне до отправки их доверенному источнику, даже если протокол передачи действия атрибут HTTPS.
6) Пока вы придерживаетесь VALID XHTML, CSS и текста почти для всех возможных аспектов взаимодействия с пользователем и общаетесь только по HTTPS, у вас все будет в порядке.
Вы должны помнить, что банки и учебные заведения получают 40% всех известных атак, поэтому вы ДОЛЖНЫ предполагать, что ваша работа будет атакована и скомпрометирована. Средняя стоимость одной атаки в 2008 году составила 11,3 миллиона долларов. Если бы банк мог атаковать вас за эти убытки, потому что вы не учли всю глубину безопасности, как бы вы ответили? Составьте соответствующий план, чтобы обеспечить максимально возможную блокировку вашей работы.