[ Pobierz całość w formacie PDF ]
.For example, so-called ``hidden fields'' andcookie values can be changed by the client before being received by CGI programs.These cannot be trustedunless special precautions are taken.For example, the hidden fields could be signed in a way the client cannotforge as long as the server checks the signature.The hidden fields could also be encrypted using a key onlythe trusted server could decrypt (this latter approach is the basic idea behind the Kerberos authenticationsystem).InfoSec labs has further discussion about hidden fields and applying encryption athttp://www.infoseclabs.com/mschff/mschff.htm.In general, you're better off keeping data you care about atthe server end in a client/server model.In the same vein, don't depend on HTTP_REFERER for authenticationin a CGI program, because this is sent by the user's browser (not the web server).This issue applies to data referencing other data, too.For example, HTML or XML allow you to include byreference other files (e.g., DTDs and style sheets) that may be stored remotely.However, those externalreferences could be modified so that users see a very different document than intended; a style sheet could bemodified to ``white out'' words at critical locations, deface its appearance, or insert new text.External DTDscould be modified to prevent use of the document (by adding declarations that break validation) or insertdifferent text into documents [St.Laurent 2000].Chapter 7.Structure Program Internals and Approach 89 Secure Programming for Linux and Unix HOWTO7.12.Set up a Trusted PathThe counterpart to needing trustworthy channels (see Section 7.11) is assuring users that they really areworking with the program or system they intended to use.The traditional example is a ``fake login'' program.If a program is written to look like the login screen of asystem, then it can be left running.When users try to log in, the fake login program can then capture userpasswords for later use.A solution to this problem is a ``trusted path.'' A trusted path is simply some mechanism that providesconfidence that the user is communicating with what the user intended to communicate with, ensuring thatattackers can't intercept or modify whatever information is being communicated.If you're asking for a password, try to set up trusted path.Unfortunately, stock Linux distributions and manyother Unixes don't have a trusted path even for their normal login sequence.One approach is to requirepressing an unforgeable key before login, e.g., Windows NT/2000 uses ``control-alt-delete'' before loggingin; since normal programs in Windows can't intercept this key pattern, this approach creates a trusted path.There's a Linux equivalent, termed the Secure Attention Key (SAK); it's recommended that this be mapped to``control-alt-pause''.Unfortunately, at the time of this writing SAK is immature and not well-supported byLinux distributions.Another approach for implementing a trusted path locally is to control a separate displaythat only the login program can perform.For example, if only trusted programs could modify the keyboardlights (the LEDs showing Num Lock, Caps Lock, and Scroll Lock), then a login program could display arunning pattern to indicate that it's the real login program.Unfortunately, since in current Linux normal userscan change the LEDs, the LEDs can't currently be used to confirm a trusted path.Sadly, the problem is much worse for network applications.Although setting up a trusted path is desirable fornetwork applications, completely doing so is quite difficult.When sending a password over a network, at thevery least encrypt the password between trusted endpoints.This will at least prevent eavesdropping ofpasswords by those not connected to the system, and at least make attacks harder to perform.If you'reconcerned about trusted path for the actual communication, make sure that the communication is encryptedand authenticated (or at least authenticated).It turns out that this isn't enough to have a trusted path to networked applications, in particular for web-basedapplications.There are documented methods for fooling users of web browsers into thinking that they're atone place when they are really at another.For example, Felten [1997] discusses ``web spoofing'', where usersbelieve they're viewing one web page when in fact all the web pages they view go through an attacker's site(who can then monitor all traffic and modify any data sent in either direction).This is accomplished byrewriting URL.The rewritten URLs can be made nearly invisible by using other technology (such asJavascript) to hide any possible evidence in the status line, location line, and so on.See their paper for moredetails.Another technique for hiding such URLs is exploiting rarely-used URL syntax, for example, the URL``http://www.ibm.com/stuff@mysite.com'' is actually a request to view ``mysite.com'' (a potentiallymalevolent site) using the unusual username ``www.ibm.com/stuff' [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl centka.pev.pl
.For example, so-called ``hidden fields'' andcookie values can be changed by the client before being received by CGI programs.These cannot be trustedunless special precautions are taken.For example, the hidden fields could be signed in a way the client cannotforge as long as the server checks the signature.The hidden fields could also be encrypted using a key onlythe trusted server could decrypt (this latter approach is the basic idea behind the Kerberos authenticationsystem).InfoSec labs has further discussion about hidden fields and applying encryption athttp://www.infoseclabs.com/mschff/mschff.htm.In general, you're better off keeping data you care about atthe server end in a client/server model.In the same vein, don't depend on HTTP_REFERER for authenticationin a CGI program, because this is sent by the user's browser (not the web server).This issue applies to data referencing other data, too.For example, HTML or XML allow you to include byreference other files (e.g., DTDs and style sheets) that may be stored remotely.However, those externalreferences could be modified so that users see a very different document than intended; a style sheet could bemodified to ``white out'' words at critical locations, deface its appearance, or insert new text.External DTDscould be modified to prevent use of the document (by adding declarations that break validation) or insertdifferent text into documents [St.Laurent 2000].Chapter 7.Structure Program Internals and Approach 89 Secure Programming for Linux and Unix HOWTO7.12.Set up a Trusted PathThe counterpart to needing trustworthy channels (see Section 7.11) is assuring users that they really areworking with the program or system they intended to use.The traditional example is a ``fake login'' program.If a program is written to look like the login screen of asystem, then it can be left running.When users try to log in, the fake login program can then capture userpasswords for later use.A solution to this problem is a ``trusted path.'' A trusted path is simply some mechanism that providesconfidence that the user is communicating with what the user intended to communicate with, ensuring thatattackers can't intercept or modify whatever information is being communicated.If you're asking for a password, try to set up trusted path.Unfortunately, stock Linux distributions and manyother Unixes don't have a trusted path even for their normal login sequence.One approach is to requirepressing an unforgeable key before login, e.g., Windows NT/2000 uses ``control-alt-delete'' before loggingin; since normal programs in Windows can't intercept this key pattern, this approach creates a trusted path.There's a Linux equivalent, termed the Secure Attention Key (SAK); it's recommended that this be mapped to``control-alt-pause''.Unfortunately, at the time of this writing SAK is immature and not well-supported byLinux distributions.Another approach for implementing a trusted path locally is to control a separate displaythat only the login program can perform.For example, if only trusted programs could modify the keyboardlights (the LEDs showing Num Lock, Caps Lock, and Scroll Lock), then a login program could display arunning pattern to indicate that it's the real login program.Unfortunately, since in current Linux normal userscan change the LEDs, the LEDs can't currently be used to confirm a trusted path.Sadly, the problem is much worse for network applications.Although setting up a trusted path is desirable fornetwork applications, completely doing so is quite difficult.When sending a password over a network, at thevery least encrypt the password between trusted endpoints.This will at least prevent eavesdropping ofpasswords by those not connected to the system, and at least make attacks harder to perform.If you'reconcerned about trusted path for the actual communication, make sure that the communication is encryptedand authenticated (or at least authenticated).It turns out that this isn't enough to have a trusted path to networked applications, in particular for web-basedapplications.There are documented methods for fooling users of web browsers into thinking that they're atone place when they are really at another.For example, Felten [1997] discusses ``web spoofing'', where usersbelieve they're viewing one web page when in fact all the web pages they view go through an attacker's site(who can then monitor all traffic and modify any data sent in either direction).This is accomplished byrewriting URL.The rewritten URLs can be made nearly invisible by using other technology (such asJavascript) to hide any possible evidence in the status line, location line, and so on.See their paper for moredetails.Another technique for hiding such URLs is exploiting rarely-used URL syntax, for example, the URL``http://www.ibm.com/stuff@mysite.com'' is actually a request to view ``mysite.com'' (a potentiallymalevolent site) using the unusual username ``www.ibm.com/stuff' [ Pobierz całość w formacie PDF ]