지난 몇 년 동안 전 세계의 소프트웨어 엔지니어들은 프로그래밍을 위해 Rust를 충분히 사용할 수 없는 것 같습니다. Mozilla에서 개발한 이 비교적 새로운 시스템 프로그래밍 언어는 스택 오버플로 커뮤니티의 마음을 사로잡았으며, 바보짓을 할 가능성이 거의 없는 집단이 5년 연속'가장 사랑받는 프로그래밍 언어'에 투표한 것을 보면 우리 모두가 주목할 때입니다.

Rust 프로그래밍 언어는 일반적으로 사용되는 언어에서 알려진 기능적 요소를 통합하여 복잡성을 처리하는 동시에 성능과 안전성을 도입하는 다른 철학에 따라 작동합니다. 러스트는 학습 곡선을 그리며, 많은 개발자가 러스트를 사용할 기회를 얻지 못하고 있으며, 스택 오버플로에서 설문조사에 참여한 응답자 중 5.1%만이 러스트를 일반적으로 사용했습니다. 그럼에도 불구하고 흥미로운 언어이며 C와 C++ 같은 이전 언어보다 훨씬 더 강력한 보안 기능을 갖춘 언어라는 점은 부인할 수 없습니다. 대규모 채택을 위해서는 행동적, 기술적 측면에서 약간의 변화가 필요하겠지만, 현재로서는 이론적 수준에서 개발자들의 관심을 끌고 있습니다.  

잠시만요, 한 가지 더 짚고 넘어가야 할 것이 있습니다. Rust는 메모리 안전과 일반적인 메모리 관리 문제와 결합된 보안 버그 근절을 우선시하는 프로그래밍 언어라는 점에 유의해야 합니다. 이러한 문제는 큰 문제이지만(의심할 여지 없이 많은 앱 보안 팀의 골칫거리입니다), 보안 코딩에서 직면하는 유일한 문제는 아닙니다.

Rust는 정확히 무엇을 방지할 수 있을까요? 그리고 보안 환경에서 우리는 여전히 어디에 노출되어 있을까요? 최신 프로그래밍 유니콘에 대해 자세히 알아봅시다:

현대의 메모리 안전 시스템 프로그래밍의 새로운 개척지

Mozilla의 연구 개발팀은 몇 가지 놀라운 프로젝트를 수행해 왔으며, 오픈 소스 선구자로서 Rust 프로그래밍에 투자하는 것도 예외는 아닙니다. 소개 동영상을 통해 개발팀의 정신을 엿볼 수 있는데, 핵심 주제는 소프트웨어 보안에 대한 현재의 접근 방식에는 결함이 있으며 Rust는 이러한 문제의 상당 부분을 해결하도록 설계되었다는 것입니다.

이지젯이보고한 최근의 끔찍한 실수처럼 매일 엄청난 데이터 유출에 직면하기 때문에 너무 단순해 보입니다. 수백만 개의 데이터 레코드가 자주 손상되며 거의 항상 웹 응용 프로그램 취약점, 보안 오용또는 피싱 공격 및 C++와 같은 언어가 수십 년 동안 존재했습니다. 그러나 개발자가 보안 코딩 모범 사례를 구현하는 시점까지 이를 마스터할 시간이 충분하지 않았습니다. 왜 녹은 다른해야 합니까? 이전에 새로운 언어가 나왔고 일반적인 취약점을 근절하거나 컴파일 할 때 작성된 코드가 마술처럼 완벽하도록 하는 방법을 찾은 것과는 다 아닙니다.

개념은 간단하지만, 때로는 복잡한 질문을 정복 간단한 답변입니다. Rust는 모든 의미에서 여러 가지 방법으로 약속을 전달하는 메모리 안전 시스템 프로그래밍의 혁명입니다... 그리고 그것은 확실히 발견 되지 않으면 큰 문제를 일으킬 수 있는 오류를 도입에 취약 개발자의 베이컨을 저장. 자바, C, C++, 그리고 Kotlin 및 Golang과 같은 최신 언어는 보안이 모르는 개발자에게 상당히 용서하지 않습니다. 그와 함께, 더 구운 경고가 없습니다, 방금 컴파일 된 멋진 기능이 후드 아래에 숨어 보안 그렘린이 특별한 징후가 없습니다.

그래서, 더 깊이 파고 보자 :

Rust를 그렇게 안전하게 만드는 이유는 무엇입니까?

일반적으로 개발자는 기능을 구축하여 기능적이고 사용자 친화적이라는 주요 목표를 가지고 있으며, 이력서에서 기꺼이 선보일 수 있다는 자부심의 근원일 수도 있습니다. 개발자가 훌륭한 소프트웨어를 만들고 배송하고 다음 큰 프로젝트로 이동하는 것은 완전히 정상입니다. 이 시점에서 보안 팀은 취약점을 확인하고 발견되면 "완료된" 응용 프로그램이 핫픽스를 위해 팀으로 반송될 수 있습니다. 문제는 간단할 수 있거나 개발자가 수정할 수 있는 합리적인 범위를 완전히 벗어날 수 있습니다.

문제는 표면 수준에서 보안 버그가 전혀 명확하지 않았으며 스캔, 테스트 및 수동 코드 검토가 검색, 테스트 및 수동 코드 검토가 선택되지 않으면 공격자가 버그를 악용할 수 있는 작은 기회를 사용할 수 있다는 것입니다.

이제 Rust는 많은 취약점이 코드로 들어가는 것을 막으려고 합니다. 이것은 소프트웨어가 실행되는 방법에 관계없이 잘못된 메모리에 액세스할 수 없도록 설계하여 메모리에 안전한 프로그래밍입니다. 그리고 모든 보안 버그의 70 %가 메모리 관리 관련 문제의 결과로,이것은 큰 위업이다.

녹은 플래그와 방지합니다 :

• 버퍼 오버플로
• 무료 사용 후
• 더블 프리
• Null 포인터 참조
• 이의되지 않은 메모리 사용

Rust 코드 스니펫과 C++를 비교하면 기본적으로 안전하다는 것이 명백해집니다. 버퍼 오버플로 버그의 이 예를 확인하십시오.

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}

대.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust는 보안 경고를 표시하고 런타임에 copy_from_slice 함수에 도달하면 패닉을 일으켜 버퍼 오버플로우를 방지하지만 컴파일 타임에는 그렇지 않습니다.

그런 의미에서, 그것은 매우 "왼쪽 시작"언어 중 하나입니다. 오류를 강조하고 개발자에게 메모리 관련 보안 버그를 도입하지 않도록 코드를 작성하는 올바른 방법을 강제로 가르치므로 마감일을 충족하는 것은 코더가 주의를 기울이고 수정하며 배달 경로에 충실하게 유지되는 데 달려 있습니다.

이 언어의 접근 방식은 간단해 보이지만, 이 강력한 논리로 작동하도록 하는 것은 놀라운 일이었을 것이며, 실제로 그렇게 하고 있습니다. 보안 관점에서 볼 때 Rust는 엄청난 도약입니다... 더 많은 사람들이 사용한다면 말입니다. Dropbox와 같은 회사들이 대규모 기업에서 이 기능을 선도적으로 사용하고 있는 것은 매우 고무적인 일입니다. 하지만 도입 문제 때문에 더 안전한 미래로 나아가지 못한다고 결론을 내리기 전에 고려해야 할 사항이 더 많습니다.

녹 계산.

몇 가지 크고 작은 문제가 있는데, Rust로 프로그래밍하면 생각보다 버그가 더 많이 발생할 수 있다는 점입니다. 보안 침해, 지연, 안전하지 않은 코딩 기술의 일반적인 문화를 계속 유발하는 가장 중요한 OWASP 상위 10개 취약점을 수정하지는 못 합니다. 천사와 악마의 역학 관계, 또는 더 널리 알려진 것처럼 안전한 녹과 안전하지 않은 녹이라는 개념도 있습니다.

공식 문서에 설명된 바와 같이 세이프 러스트는 "진정한" 형태의 러스트이며, 언세이프 러스트에는 다른 언어로 된 무언가와 통합이 필요한 경우와 같이 때로는 필요하지만 "절대 안전하지 않은" 것으로 간주되는 기능이 포함되어 있습니다. 그러나 Unsafe Rust를 사용하더라도 추가 기능 목록은 여전히 제한적입니다. 안전하지 않은 Rust에서는 안전하지 않은 블록 내에서 다음과 같은 작업을 수행할 수 있습니다:

• 참조 해제 원시 포인터
• 안전하지 않은 함수(C 함수, 컴파일러 내장 및 원시 할당자 포함)를 호출합니다.
• 안전하지 않은 특성 구현
• 돌연변이 정적
• 공용 공용 리소스의 액세스 필드입니다.

소위 "안전하지 않은" 모드에서도 Rust 프로그래밍의 강력한 기능 중 하나인 "차용 검사기"는 여전히 작동합니다. 일반적으로 정적 코드 분석을 통해 메모리 문제, 병렬 계산의 충돌 및 기타 여러 버그를 방지하며, 이 분석은 여전히 안전하지 않은 블록에서 검사를 수행합니다. 다만 특정 상황에서 컴파일러가 지침을 제공하지 않고 안전하지 않은 구성을 작성하려면 훨씬 더 많은 작업이 필요할 뿐입니다.

대부분의 숙련된 개발자에게는 큰 문제가 되지 않는 것처럼 보이지만, 애플리케이션을 최대한 활용하고 더 멋진 기능을 추가하기 위해 땜질하는 것으로 잘 알려져 있지만, 정의되지 않은 동작이라는 심각한 구성 오류와 보안 취약점으로 이어질 수 있는 블랙홀이 될 수 있습니다. Rust로 프로그래밍하면(안전하지 않게 사용하더라도) C 또는 C++에 비해 취약점의 가능성을 상당히 차단할 수 있지만, 정의되지 않은 동작을 호출하는 것은 위험할 수 있습니다.

이것이 개발자 주도의 보안 코딩에 대한 의존의 끝입니까?

앞서 Rust가 잘 알려진 언어의 구성 요소를 가지고 있다고 말씀드렸던 것을 기억하시나요? Rust의 주요 보안 취약점 중 하나는 잘 알려진 언어의 구성 요소, 즉 C를 포함하고 있다는 것입니다.

Rust는 여전히 "안전한 프로그래밍 언어"이지만 다시 사용자의 도입은 상황이 멈출 수 있는 곳입니다. 개발자는 여전히 오류 플래그없이 실행하도록 조정할 수 있습니다 (매력적인 제안, 이 더 많은 기능을 잠금을 해제하기 때문에), 본질적으로, 심지어 안전한 상태에서, 개발자는 여전히 "안전하지 않은"될 수 있습니다, 그들은 일이 정말 배 모양으로 갈 수 있기 전에 지도와 보호의 레이어를 가지고 있기 때문에, 그들은 여전히 그들이 원하는대로 "안전하지 않은"될 수 있습니다.

위의 두 가지 시나리오는 더 깊이 파고들수록 더 위험해집니다. Rust의 결과는 스캔 도구와 유사하기 때문입니다. 모든 취약점, 모든 공격 벡터 및 모든 문제를 스캔하는 스위스 군용 SAST/DAST/RAST/IAST 도구가 없는 것처럼 Rust도 마찬가지입니다. Rust를 사용하더라도 일부 취약점은 여전히 매우 쉽게 도입될 수 있습니다.

안전하지 않은 Rust를 실행할 때 정의되지 않은 동작 위험은 정수 오버플로 문제를 열 가능성이 있으며 일반적으로 안전한 구성조차도 보안 오작동, 비즈니스 논리또는 알려진 취약점이 있는 구성 요소의 인적 오류를 방지하지 못합니다. 이러한 문제는 패치를 남기지 않은 경우 여전히 매우 실질적인 위협을 제기하고, 진정한 Rust와 같은 "가정 된 안전한"환경에서 코더가 모든 주요 문제가 관계없이 포착 될 것이라고 생각하면 일부 자만심을 유발할 수도 있습니다.

저는 Rust가 경험이 부족한 코더와 함께 시간을 내어 작업을 검토하고 잠재적인 버그를 보여주고, 효율성을 지적하고, 경우에 따라서는 제대로 컴파일될 때까지 컴파일하지 않도록 하는 선임 엔지니어인 프로그래밍 멘토와 다르지 않다는 것을 알게 되었습니다. 하지만 멘토가 앞치마만 두르고 가버릴 수 있으므로 Rust 프로그래머가 직접 이론을 배우고 모범 사례에 전념하는 것이 훨씬 더 좋습니다.

지금 바로 일반적인 Rust 취약점을 찾아 수정할 준비가 되셨나요? 챌린지를 플레이하세요.