令人遺憾的是，如果是整型數(shù)據(jù)出了語義上的問題，沒有什么東西可以替語義背黑鍋了，所以沒有了一個一定程度上通用的解決方案。不過也不要悲觀，前面就已經(jīng)說過，能避開就避開，釜底抽薪不要讓可能有語義問題的變量作為輸入好了。

僅僅考慮數(shù)據(jù)庫安全的話，所有有威脅的語義問題都幾乎出在對數(shù)據(jù)庫的操作上，那么，我們只要注意update/insert等語句就可以了，如果考慮數(shù)據(jù)內(nèi)容的安全性的話，select也得算上。一般來說，特別關(guān)注的是生成的where后面的條件語句，總覺得條件的語義應(yīng)該是由服務(wù)器端決定的，而不是說用戶的輸入是什么就是什么。我的建議是對于所有的可能出現(xiàn)語義問題的整型變量，最好都是Session，當(dāng)然，沒有進(jìn)行非常深入的研究，或許有人能夠提出像對付字符串的語義問題一樣的有效方法也說不一定。不過話又說回來，在語義層面上看對字符串的過濾，不能證明它不安全，但是更重要的沒有人能夠證明它安全，只是大家現(xiàn)在用著沒有問題，也就默認(rèn)了罷了。

若要深入的分析語義，也會突然冒出一大堆奇怪的東西，所以還是就此打住吧，真切的希望同行之間能夠多一些這方面的交流！

前面說的也許更多地會用在一些對既有代碼的補救上，如果是從頭開始構(gòu)架一個軟件的話，上面的僅僅是設(shè)計上一些參考。所有的漏洞都是源于設(shè)計上的缺陷，一個好的軟件應(yīng)該被證明其模型是正確的，這很難但是可以做到。如果你一開始就證明了軟件的正確性，我想也不會有漏子可以給別人鉆了。