eval (parse (…))의 위험은 구체적으로 무엇입니까?

eval (parse (…))의 위험은 구체적으로 무엇입니까?

---

사용을 피하는 방법에 대한 몇 가지 질문이 있습니다. eval(parse(...))

• r-evalparse는 종종 차선책입니다
• 악명 높은 평가 구문 분석 피하기

질문의 원인 :

• 특히 eval(parse())피해야하는 이유는 무엇 입니까?
• 그리고 가장 중요한 것은 위험이 무엇입니까?
  • 프로덕션에서 코드를 사용하지 않으면 위험합니까? (의도하지 않은 결과를 얻을 위험이 있다고 생각합니다. 파싱하는 내용에 대해주의하지 않으면 문제가 발생할 것입니다.하지만 그게 엉성한 것보다 더 위험한 get()가요?)

---

대부분의 반대 주장 은 보안 문제 때문 eval(parse(...))이 아니라 결국 R이 인터넷에 노출되는 안전한 인터페이스라는 주장이 제기되지 않습니다. 오히려 그러한 코드가 일반적으로 덜 모호한 방법을 사용하여 수행 할 수있는 작업을 수행하기 때문입니다. 더 빠르고 인간적인 구문 분석이 가능한 메소드. R 언어는 높은 수준이어야합니다. 그래서 cognoscenti의 선호도는 (그리고 저는 그 그룹에 속한다고 생각하지 않습니다) 간결하고 표현적인 코드를 보는 것입니다.

따라서 위험은 eval(parse(..))지식 부족을 극복하는 백도어 방법이며 그 장벽을 높이는 희망은 사람들이 R 언어 사용을 개선 할 것이라는 것입니다. 문은 열려 있지만 다른 기능을보다 표현 적으로 사용하는 것이 희망입니다. 오늘 초 Carl Witthoft의 질문 은 get기능이 사용 가능 하다는 것을 알지 못 했으며 그가 연결 한 질문 은 [[기능 이 어떻게 작동하는지 (그리고 어떻게 $더 제한적 이었는지) 에 대한 이해 부족 을 드러 냈습니다[[ . 두 경우 모두 eval(parse(..))솔루션을 구성 할 수 있지만 대안보다 명확하지 않고 명확하지 않았습니다.

---

보안 문제는 다른 사용자가 전달한 문자열에 대해 eval 호출을 시작하는 경우에만 실제로 발생합니다. 백그라운드에서 R을 실행하는 응용 프로그램을 만드는 경우 큰 문제이지만 직접 실행할 코드를 작성하는 데이터 분석의 경우 eval보안 에 대한 영향에 대해 걱정할 필요가 없습니다 .

eval(parse(그래도 다른 문제가 있습니다.

첫째, eval-parse를 사용하는 코드는 일반적으로 구문 분석되지 않은 코드보다 디버깅하기가 훨씬 더 어렵습니다. 이는 소프트웨어 디버깅 이 처음에 작성하는 것 보다 두 배 더 어렵 기 때문에 문제가 됩니다.

여기에 실수가있는 함수가 있습니다.

std <- function()
{
  mean(1to10)
}

바보 같은데, 콜론 연산자를 잊고 벡터를 잘못 만들었습니다. 이 함수를 시도하고 소싱하면 R이 문제를 발견하고 오류를 발생시켜 내 실수를 지적합니다.

다음은 eval-parse 버전입니다.

ep <- function()
{
  eval(parse(text = "mean(1to10)"))
}

이것은 것이다 오류가 유효한 문자열 내부에 있기 때문에, 소스. 나중에 오류가 발생하는 코드를 실행해야합니다. 따라서 eval-parse를 사용하여 소스 시간 오류 검사 기능을 잃었습니다.

또한이 두 번째 버전의 함수는 읽기가 훨씬 더 어렵다고 생각합니다.

eval-parse의 또 다른 문제는 직접 실행되는 코드보다 훨씬 느리다는 것입니다. 비교

system.time(for(i in seq_len(1e4)) mean(1:10))
   user  system elapsed 
   0.08    0.00    0.07

과

system.time(for(i in seq_len(1e4)) eval(parse(text = "mean(1:10)")))
   user  system elapsed 
   1.54    0.14    1.69

---

일반적으로 코드 문자열로 작업하는 것보다 '언어로 계산'하는 더 좋은 방법이 있습니다. evalparse Heavy-code는 내 경험상 합리적인 출력을 보장하기 위해 많은 보호 장치가 필요합니다.

동일한 작업은 일반적으로 R 코드를 언어 객체로 직접 작업하여 해결할 수 있습니다. Hadley Wickham은 R의 메타 프로그래밍에 대한 유용한 가이드를 제공 합니다 .

gtools 라이브러리의 defmacro () 함수는 evalparse 구문에 대한 제가 가장 좋아하는 대체품입니다 (반쪽 R 말장난이 아닙니다).

require(gtools)

# both action_to_take & predicate will be subbed with code

F <- defmacro(predicate, action_to_take, expr = 
    if(predicate) action_to_take)

F(1 != 1, action_to_take = print('arithmetic doesnt work!'))

F(pi > 3, action_to_take = return('good!'))
[1] 'good!'

# the raw code for F
print(F)

function (predicate = stop("predicate not supplied"), action_to_take = stop("action_to_take not supplied")) 
{
    tmp <- substitute(if (predicate) action_to_take)
    eval(tmp, parent.frame())
}
<environment: 0x05ad5d3c> 

이 방법의 이점은 구문 상 합법적 인 R 코드를 다시 얻을 수 있다는 것입니다. 이 유용한 기능에 대한 자세한 내용은 여기 에서 찾을 수 있습니다 .

도움이 되었기를 바랍니다.

---

In some programming languages, eval() is a function which evaluates a string as though it were an expression and returns a result; in others, it executes multiple lines of code as though they had been included instead of the line including the eval. The input to eval is not necessarily a string; in languages that support syntactic abstractions (like Lisp), eval's input will consist of abstract syntactic forms. http://en.wikipedia.org/wiki/Eval

There are all kinds of exploits that one can take advantage of if eval is used improperly.

An attacker could supply a program with the string "session.update(authenticated=True)" as data, which would update the session dictionary to set an authenticated key to be True. To remedy this, all data which will be used with eval must be escaped, or it must be run without access to potentially harmful functions. http://en.wikipedia.org/wiki/Eval

In other words, the biggest danger of eval() is the potential for code injection into your application. The use of eval() can also cause performance issues in some languages depending on what is being used for.

Specifically in R, it's probably because you can use get() in place of eval(parse()) and your results will be the same without having to resort to eval()

참고URL : https://stackoverflow.com/questions/13649979/what-specifically-are-the-dangers-of-evalparse