2012-09-27 41 views
0

我聽說過很多關於eval的壞事,我從未嘗試過使用它。然而今天我有一種情況,似乎是正確的答案。這是安全嗎? eval或new函數用於簡單的算術表達式

我需要一個腳本,可以通過組合變量做簡單的計算。例如,如果value = 5和max = 8,我想評估值* 100/max。值和公式都將從外部來源檢索,這就是爲什麼我關心eval。

我已經建立了一些示例代碼的jsfiddle演示:

http://jsfiddle.net/6yzgA/

的值轉換爲使用parseFloat數,所以我相信我敢這裏安全。公式中的字符匹配的再次正則表達式:

regex=/[^0-9\.+-\/*<>!=&()]/, // allows numbers (including decimal), operations, comparison 

我的問題:

  • 難道我的正則表達式過濾器保護我不受任何攻擊?
  • 沒有任何理由使用eval與新功能在這種情況下?
  • 是否有另一種更安全的方式來評估公式?

回答

3

由於您沒有向您的服務器發送任何內容或在任何其他系統上使用任何內容,因此最糟糕的情況是用戶崩潰了自己的瀏覽器。在這裏使用eval沒有什麼不安全的,因爲一切都發生在用戶端。

+0

+1我同意...'eval'是更危險的服務器端語言,如PHP。對於客戶端語言(如Javascript)來說,這並不是什麼大問題。 – Travesty3

+0

我在演示中使用了輸入字段,但正如我在問題中所說的那樣,值和公式實際上來自外部來源。我擔心惡意源可能會推送一個不安全的公式(腳本標記或onload事件或其他我無法想象的東西) – Christophe

+0

@Travesty3'eval'在客戶端也可能會非常危險並且用於跨站點腳本。 http://en.wikipedia.org/wiki/Cross_site_scripting然而,在這個例子中它是完全安全的,我同意。 –

0

逃逸,防止在客戶端的東西沒有意義可言。用戶可以修改任何一段JS代碼並運行它,就像我可以更改發佈的jsfiddle一樣簡單。相信我,這就是這麼簡單,你不能依賴於客戶端的安全。

如果你還記得逃脫在服務器端輸入字段沒什麼可擔心的。根據您使用的語言,默認情況下有很多功能。

如果用戶想在<script>haxx(l33t);</script>鍵入 - 讓他去做。只記得要逃脫特殊字符,所以你會有&lt;script&gt;haxx(l33t);&lt;/script&gt;

+0

我並不擔心用戶傷害自己,而是受到外部來源的傷害(參考我的問題和我對@ Kolink的回答的評論)。轉義特殊字符聽起來像是一個好主意,問題是它會破壞我的驗證表達式(大於,小於)。 – Christophe

+0

的確如此。因此,您可能必須制定您的自定義正則表達式並對其進行徹底測試。 –