Drošība: Top-20 2007 Security Risks

[Aleksejs]

Iesaku izlasīt visiem visu rakstu. Īpaši jau šim forumam aktuālo daļu par web aplikācijām.

http://www.sans.org/top20/2007/printer.htm#s1

 

Tiem, kas interesējas par tēmu nekā ļoti jauna nebūs, taču apkopojums sniedz ieskatu, kādas problēmas ir "topā" šobrīd.

 

Atļaušos ielikt ieteikumu izvilkumu:

S1.3 How to Protect against Web Application Vulnerabilities

 

From the PHP system administration and hosting perspective:

• Upgrade to PHP 5.2 as it eliminates many latent PHP security issues and allows for safer APIs, such as PDO
   
  
• Always test and deploy patches and new versions of PHP as they are released
   
  
• Frequent web scanning is recommended in environments where a large number of PHP applications are in use
   
  
• Consider using the following PHP configuration:
  
  • register_globals (should be off, will break insecure apps)
     
    
  • allow_url_fopen (should be off, will break apps that rely on this feature, but protect against a very active exploit vector)
     
    
  • magic_quotes_gpc (should be off, will break older insecure apps)
     
    
  • open_basedir (should be enabled and correctly configured)
     
    
  • Consider using least privilege execution features like PHPsuexec or suPHP
     
    
  • Consider using Suhosin to control the execution environment of PHP scripts
    

  [*] Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks

   

  [*] As a last resort, consider banning applications which have a track record of active exploitation, and slow response times to fix known security issues.

From the developer perspective:

• If you use PHP, migrate your application to PHP 5.2 as a matter of urgency.
   
  
• To avoid the coding issues above:
  • Develop with the latest PHP release and a hardened configuration (see above)
     
    
  • Validate all input according to the variable type it is being assigned
     
    
  • Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks
     
    
  • Migrate your data layer to PDO - do not use the old style mysql_*() functions as they are known to be faulty
     
    
  • Do not use user-supplied input with file functions to avoid remote file inclusion attacks
    

  [*] Join secure coding organizations, such as OWASP (see references) to boost skills, and learn about secure coding

   

  [*] Test your apps using the OWASP Testing Guide with tools like WebScarab, Firefox's Web Developer Toolbar, Greasemonkey and the XSS Assistant

   

  [*] Measure your skill using the GSSP exams and fill in the gaps in your knowledge.

Edited December 4, 2007 by Aleksejs

[betons]

Migrate your data layer to PDO - do not use the old style mysql_*() functions as they are known to be faulty

 

1)Vai šeit ir jau kāds, kurš regulāri izmanto PDO? Un vispār tas citāts jāuztver kaut cik nopietni?

 

2)Vai bindValue() pasargā no SQL injekcijām?

Edited December 4, 2007 by betons

[Aleksejs]

1) Nē neizmantoju PDO. Cik nopietni tas ieteikums arī grūti pateikt - katram tās vajadzības un pieļaujamie riski ir citādi.

2) Domāju, ka nē, jo SQL injekcijas ir nedaudz plašāks jēdziens, par datu atbilstības datu tipam kontroli. Taču, kā jau teicu, PDO nelietoju.

[Delfins]

mysql_*() functions as they are known to be faulty

miljoniem/miljardiem webu strādā ar tām.. un it kā viss ok. Tā kā tas ir principiāls jautājums... Drīzāk grib visus piesiet kaut kāda viena extensiona. (moš google-ads leks no SQL rezulta.. hvz.. viss ir iespējams)

[Aleksejs]

Man atkal ir cits jautājums:

Kāda ir šejieniešu attieksme pret http://www.owasp.org It kā biedru no Latvijas nav.

[betons]

miljoniem/miljardiem webu strādā ar tām.. un it kā viss ok. Tā kā tas ir principiāls jautājums... Drīzāk grib visus piesiet kaut kāda viena extensiona. (moš google-ads leks no SQL rezulta.. hvz.. viss ir iespējams)

 

Man jau arī liekas, ka tās ir kautkādas pilnīgas muļķības, jo mysql_... un mysqli_... tak ir iedzimtās MySQL funkcijas, un, IMHO, tām vajadzētu strādāt ātrāk un stabilāk par jebkuriem citiem extensioniem un visādiem PDO.

[Aleksejs]

Njā, man arī īsti nav skaidrs, ko viņi ar to domājuši.

Pameklējot atradu dažus:

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4889

http://secweb.se/en/advisories/php-mysql-s...-vulnerability/

Nu, nezinu - man šķiet, ka galvenā morāle - izmantot frameworkus, kuros ir piedomāts par drošību, un nevis pārāk jaudīgas funkcijas, kas ļauj iešaut sev kājā.

P.S. Ātrdarbība uz drošības rēķina ir nevēlama ;)