Здравствуйте, DOOM, Вы писали:
DOO>·>А вообще интересно. Допустим, ebay и правда хочет разрешить вставку пользовательских js скриптов (интересно зачем?) на страницу, что сделать чтобы обеспечить безопасность? DOO>В идеале, надо сделать свой интерпретатор, который гарантирует выполнение только тех команд, которые заложил автор. Понятно, что писать интерпретатор JS на JS — то еще удовольствие (очевидно, что это не eval(str) будет )
Ну да, это в самом общем случае. И это не только сам язык, но и скажем DOM-дерево, css-селекторы, етс. Например, дать полный доступ к частям страницы описания товара, но не к кнопке login самого сайта.
DOO>·>По-моему, единственное нормальное решение — это поддержка на уровне браузеров, чтобы можно было создавать безопасные js-песочницы, изолированные контексты внутри страницы. DOO>Т.е. по сути Java с жесткой системой разрешений. Но это надо менять браузеры — хотя кое-что уже есть (например, код из js может попросить разрешить всплывающие окна, push уведомления и т.п. — просто все это, насколько я знаю, не стандарт ни разу, а зависит исключительно от разработчика браузера).
Так тут ещё один уровень санд-боксинга нужен. Одно дело, когда разработчики ebay помещают скрипт, который просит разрешение, а другое дело я, как продавец, помещаю в описание товара скрипт, который прикидывается родным ebay-евским, например, рисуя фишинговое окно аутентификации.
DOO>·>Либо использовать не js, а какой-то более строгий язык, как минимум без eval, с верификацией. DOO>см. выше — свой интерпретатор на JS
Надо же, есть такое уже https://github.com/NeilFraser/JS-Interpreter
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это круто! Не думал, что эзотерический язык программирования может оказаться настолько полезен ·>http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/
В очередной раз всем напомнили, что фильтрация ввода и экранирование символов — полумеры.
Спасет только жесткая типизация пользовательских данных.
Здравствуйте, DOOM, Вы писали:
DOO>·>Это круто! Не думал, что эзотерический язык программирования может оказаться настолько полезен DOO>·>http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/ DOO>В очередной раз всем напомнили, что фильтрация ввода и экранирование символов — полумеры. DOO>Спасет только жесткая типизация пользовательских данных.
А вообще интересно. Допустим, ebay и правда хочет разрешить вставку пользовательских js скриптов (интересно зачем?) на страницу, что сделать чтобы обеспечить безопасность?
По-моему, единственное нормальное решение — это поддержка на уровне браузеров, чтобы можно было создавать безопасные js-песочницы, изолированные контексты внутри страницы.
Либо использовать не js, а какой-то более строгий язык, как минимум без eval, с верификацией.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А вообще интересно. Допустим, ebay и правда хочет разрешить вставку пользовательских js скриптов (интересно зачем?) на страницу, что сделать чтобы обеспечить безопасность?
В идеале, надо сделать свой интерпретатор, который гарантирует выполнение только тех команд, которые заложил автор. Понятно, что писать интерпретатор JS на JS — то еще удовольствие (очевидно, что это не eval(str) будет )
·>По-моему, единственное нормальное решение — это поддержка на уровне браузеров, чтобы можно было создавать безопасные js-песочницы, изолированные контексты внутри страницы.
Т.е. по сути Java с жесткой системой разрешений. Но это надо менять браузеры — хотя кое-что уже есть (например, код из js может попросить разрешить всплывающие окна, push уведомления и т.п. — просто все это, насколько я знаю, не стандарт ни разу, а зависит исключительно от разработчика браузера).
·>Либо использовать не js, а какой-то более строгий язык, как минимум без eval, с верификацией.
см. выше — свой интерпретатор на JS
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Спасет только от инъекций (XSS, SQLi, XMLi, XPATHi, XXE и т.п.) и только до тех пор, пока не понадобится тип "arbitary text"
Могу поспорить
Спасет, например, от HTTP response splitting или request forging — просто типизация тут более широкое понятие (правильнее валидация — когда мы точно знаем что может встретиться во входных параметрах и умеем корректно обработать каждый случай).
Здравствуйте, ·, Вы писали:
·>Так тут ещё один уровень санд-боксинга нужен. Одно дело, когда разработчики ebay помещают скрипт, который просит разрешение, а другое дело я, как продавец, помещаю в описание товара скрипт, который прикидывается родным ebay-евским, например, рисуя фишинговое окно аутентификации.
Ну да... Но это уже какой-то космос для современных web-приложений
DOO>>см. выше — свой интерпретатор на JS ·>Надо же, есть такое уже https://github.com/NeilFraser/JS-Interpreter
Честно говоря, я и не сомневался
Здравствуйте, DOOM, Вы писали:
KV>>Спасет только от инъекций (XSS, SQLi, XMLi, XPATHi, XXE и т.п.) и только до тех пор, пока не понадобится тип "arbitary text" DOO>Могу поспорить DOO>Спасет, например, от HTTP response splitting или request forging —
)
