Revision as of 18:09, 8 August 2013

Giriş

Bu makale, uygulamalarınızda kullanılan girdi doğrulama işlevsellikleri için temiz,basit ve dava edilebilir noktalar üzerinde rehber olmaya odaklanmıştır.

Girdi Doğrulaması Beyaz Liste

Saldırıyı mümkün olduğunca en erken aşamada, kullanıcı/saldırganın isteğini işleme tabi tutma aşamasında önlemek/önlemeye çalışmak tavsiye edilir. Girdi doğrulaması, girdinin uygulama tarafından işlenmesinden hemen önce izin verilmeyen girdileri tespit etmek için kullanılabilir. Yazılım geliştiriciler saldırı karakterlerini ve “'”,”1=1” gibi karakter dizileri yada “<script>” biçimlerini tespit edebilmek için sıklıkla kara liste doğrulamasını uygularlar,fakat bu yöntem tek olarak kullanıldığında saldırgan için kara listede ki filtrelerden kaçınmak için sadece küçük bir test olacağından dolayı tam olarak sağlıklı bir yaklaşım olmaz. Buna artı olarak, bu tür filtreler çoğu zaman “O'Brian” örneğinde olduğu gibi izin verilen girdileri de (kesme işareti) “'” filtrelendiği için engelleyebilmektedir.

Beyaz liste doğrulaması, kullanıcı tarafından sağlanan tüm girdi alanları için uygundur. Beyaz liste doğrulaması tam olarak neye veya nelere izin verileceğinin tanımlarını içerir ve bunların dışında kalan herşey ise yetkilendirilmeyecektir. Eğer girdi veri yapısı düzenli ise (mesela tarihler,sosyal güvenlik numaraları,posta kodları,eposta adresleri gibi) o zaman yazılım geliştirici her girdiyi doğrulamak için genellikle düzenli ifadelere dayalı olarak çok güçlü doğrulama motifleri tanımlayabilir. Eğer girdi alanı aşağı açılan bir listeden veya radyo düğmeleri tanımlanmış mevcut bir kümeden belirleniyorsa, o zaman ilk olarak girdi verisi kullanıcıya sunulan değerlerden biri ile eşleşmelidir. Doğrulaması en zor alanlar “özgür yazım alanları” (free text) olarak da bilinen alanlardır, bloglar gibi. Fakat, bu alanlar belirli bir dereceye kadar doğrulanabilse bile, yazdırılamayan karakterleri çıkarıp girdi alanı için maksimum kapasite tanımlaması yapabilirsiniz.

Düzenli ifadeleri geliştirmek karmaşık olabilir ve bu kılavuz dökümanının içeriğinde değildir. Lakin, internet üzerinde düzenli ifadeleri geliştirebilmek için birçok kaynak bulunabilir http://www.regular-expressions.info/ ve  OWASP Validation Regex Repository.

White List Regex Examples

 Validating Data from Free Form Text Field for Zip Code (5 digits plus optional -4) ^\d{5}(-\d{4})?$
 
 Validating Data from Fixed List Drop-Down Box For U.S. State Selection
   ^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|
   MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|TX|UT|VT|VI|VA|WA|WV|WI|WY)$
 
 Validating a Free Form Text Field for allowed chars (numbers, letters, whitespace, .-_)
   ^[a-zA-Z0-9\s._-]+$ 	 (Any number of characters)
   ^[a-zA-Z0-9\s._-]{1-100}$	 (This is better, since it limits this field to 1 to 100 characters)
 Note: \s matches any whitespace character (i.e., space, tab, carriage return, or linefeed, [ \t\r\n])
 Note: most regular expressions flavors do not need to escape the . (dot) inside character classes []
       using \. then results in two literal characters \ (backslash) and . (dot) which is most likely not wanted
 Note: the use of - inside character classes [] depends on the regular expressions flavors, possible
       variants are: unescaped if first character, unescaped if last character or must be always escaped as \-

Java Regex Usage Example

 Example validating the parameter “zip” using a regular expression.
 
 private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");
 public void doPost( HttpServletRequest request, HttpServletResponse response) {
 	try {
 		String zipCode = request.getParameter( "zip" );
 		if ( !zipPattern.matcher( zipCode ).matches()  {
 			throw new YourValidationException( "Improper zipcode format." );
 		}
 		.. do what you want here, after its been validated ..
 	} catch(YourValidationException e ) {
 		response.sendError( response.SC_BAD_REQUEST, e.getMessage() );
 	}
 }

Some white list validators have also been predefined in various open source packages that you can leverage. Two packages that provide this are:

• Apache Commons Validator
• OWASP ESAPI Validators

It is recommended that you use ESAPI to assist with your input validation needs, rather than writing your own validation routines. The OWASP Enterprise Security API (ESAPI) project has predefined validators defined in the org.owasp.esapi.Validator interface and implemented in the DefaultValidator reference implementation. These include:

• getValidDate()
• getValidSafeHTML()
• getValidInput()
• getValidNumber()
• getValidFileName()
• getValidRedirectLocation()

With ESAPI, the previous example can be rewritten as follows:

 Example validating the parameter “zip” with generic ESAPI input validator.
 
 public void doPost( HttpServletRequest request, HttpServletResponse response) {
 	try {
 		String zipCode = Validator.getValidInput("ChangeAddressPage_ZipCodeField", 
 		  request.getParameter( "zip" ), "zipCodePattern", 10, false));
 		.. do what you want with validated ‘zipCode’ param here ..
 	} catch( ValidationException e ) {
 		response.sendError( response.SC_BAD_REQUEST, e.getMessage() );
 	}
 }
 
 // zipCodePattern is the name of a property defined in ESAPI.properties, and its value
 // is the regular expression: "^\d{5}(-\d{4})?$"
 // 
 // If zipcodes were a frequently used parameter in your application, we would recommend 
 // that you create your own getValidZipCode() method that builds on top of ESAPI, to make 
 // it even simpler for your developers to use.

• The overall javadoc for ESAPI is here
• And the javadoc for this specific interface is here.

Authors and Primary Editors

Dave Wichers - dave.wichers [at] aspectsecurity.com