Skip to Content
Last modified by Pascal Robert on 2010/09/13 00:22
From version 2.1
edited by smmccraw
on 2007/07/08 09:45
Change comment: There is no comment for this version
To version 3.1
edited by David Holt
on 2009/07/30 12:21
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Programming__WebObjects-Web Applications-Development-Authentication and Security
1 +Web Applications-Development-Authentication and Security
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.smmccraw
1 +XWiki.dholt
Content
... ... @@ -1,9 +1,9 @@
1 -== Encrypted Passwords ==
1 +== Encrypted Passwords ==
2 2  
3 3  Kieran Kelleher has written an excellent article on his blog about performing encryption on an EO attribute via a custom attribute:
4 -http:~/~/homepage.mac.com/kelleherk/iblog/C729512539/E2033071041/index.html
4 +[[http://homepage.mac.com/kelleherk/iblog/C729512539/E2033071041/index.html]]
5 5  
6 -== Security Considerations ==
6 +== Security Considerations ==
7 7  
8 8  Just some tips and hints originally compiled by Anders Björklund...
9 9  
... ... @@ -16,79 +16,85 @@
16 16  * $HOSTNAME = host.domain.tld (your web server)
17 17  * $APPNAME = WOApplication name (your application)
18 18  
19 -=== The CGI adaptor application listing ===
19 +=== The CGI adaptor application listing ===
20 20  
21 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/
21 +[[http://$HOSTNAME/cgi-bin/WebObjects/]]
22 22  
23 23  Set username and password for the application listing.
24 24  
25 -=== The web server resources listing ===
25 +=== The web server resources listing ===
26 26  
27 -http:~/~/$HOSTNAME/WebObjects/
27 +[[http://$HOSTNAME/WebObjects/]]
28 28  
29 29  Don't allow directory browsing on your web server, otherwise users will be able to see all of your web server resources, and learn the names of all of your applications and frameworks that contain web server resources.
30 30  
31 -= The wotaskd config page (WO >~= 4.5) h3. =
31 +=== The wotaskd config page (WO >~= 4.5) ===
32 32  
33 -http:~/~/$HOSTNAME:1085/cgi-bin/WebObjects/wotaskd.woa/wa/woconfig
33 +[[http://$HOSTNAME:1085/cgi-bin/WebObjects/wotaskd.woa/wa/woconfig]]
34 34  
35 35  The port 1085 should not be allowed through the firewall.
36 36  
37 - The Monitor h3.
38 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/Monitor
37 +=== The Monitor ===
39 39  
39 +[[http://$HOSTNAME/cgi-bin/WebObjects/Monitor]]
40 +
40 40  Monitor should be unavailable, or at least password protected.
41 41  
42 - The xyzzy default page h3.
43 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/xyzzy
43 +=== The xyzzy default page ===
44 44  
45 +[[http://$HOSTNAME/cgi-bin/WebObjects/xyzzy]]
46 +
45 45  The name/password for the xyzzy page should be changed.
46 46  
47 - The WOStatisticsStore default page h3.
48 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOStats
49 +=== The WOStatisticsStore default page ===
49 49  
51 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOStats]]
52 +
50 50  The statistics page should be protected by a password (or off).
51 51  
52 - The WOEventDisplay default page (WO >= 4.5) h3.
53 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventDisplay
55 +=== The WOEventDisplay default page (WO >~= 4.5) ===
54 54  
57 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventDisplay]]
58 +
55 55  The events page should be be protected by a password (or off).
56 56  
57 - The WOEventSetup default page h3.
58 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventSetup
61 +=== The WOEventSetup default page ===
59 59  
60 -See http:~/~/developer.apple.com/techpubs/webobjects/EOControlRef/Java/Classes/Concepts/EOEventCenterConcepts.html
63 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventSetup]]
61 61  
62 - You can invoke a WOComponent directly if you know its name h3.
63 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wo/$COMPONENTNAME.wo
65 +See [[http://developer.apple.com/techpubs/webobjects/EOControlRef/Java/Classes/Concepts/EOEventCenterConcepts.html]]
64 64  
67 +=== You can invoke a WOComponent directly if you know its name ===
68 +
69 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wo/$COMPONENTNAME.wo]]
70 +
65 65  This can be used to navigate a site in ways not otherwise explictly allowed. In addition, a number of WOComponents with well-known names are included in the WebObjects frameworks, and are thus accessible in any WebObjects application.
66 66  
67 67  This is a very serious security issue. WOComponents that are accessed in this way are basically uninitialized (i.e., no bindings are set). In some cases, accessing an uninitialized WOComponent in this way will bring an app down. Any way in which someone can bring down your application with a simple URL call to it should be blocked.
68 68  
69 - You can invoke a DirectAction if you know its name h3.
70 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONNAME
71 -http:~/~/$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONCLASSNAME/$DIRECTACTIONNAME
75 +=== You can invoke a DirectAction if you know its name ===
72 72  
77 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONNAME]]
78 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONCLASSNAME/$DIRECTACTIONNAME]]
79 +
73 73  If someone has access to your application, then he can call any direct action he wants by using the URL above. If the DirectAction name exists, it will be called. If it does not exist, an error is thrown (which should be caught). A DirectAction that should not be randomly accessed should be secured.
74 74  If your application displays user-entered text into the HTML stream, it may be possible for them to insert a <WEBOBJECT>; tag to display a component that otherwise wouldn't be displayed.
75 75  
76 -This is tricky ~-~- the attacker would need to know the name of an existing webobject, and even then they wouldn't be able to override the parameters in the binding (.wod) file.
83 +This is tricky - the attacker would need to know the name of an existing webobject, and even then they wouldn't be able to override the parameters in the binding (.wod) file.
77 77  
78 78  Andrus Adamchik points out that because of the way WebObjects' HTML templating system works, you'd also need to explictly call WOComponent.templateWithName with the user-enterer string.
79 79  
80 - Others h1.
87 += Others =
88 +
81 81  And a few miscellaneous additions contributed by GarrickMcFarlane, a UK-based WebObjects consultant:
82 82  
83 -* If you leave multiple adaptors around (eg, on IIS, the WebObjects.dll and the WebObjects.exe) then you can apply all the security in the world to one of them whilst still leaving the other one pretty much unprotected ~-~- because they each use different names and mechanisms for determining your security settings. So, if you're using the dll, you should consider getting rid of the .exe.
91 +* If you leave multiple adaptors around (eg, on IIS, the WebObjects.dll and the WebObjects.exe) then you can apply all the security in the world to one of them whilst still leaving the other one pretty much unprotected - because they each use different names and mechanisms for determining your security settings. So, if you're using the dll, you should consider getting rid of the .exe.
84 84  * xyzzy is called WOAdaptorInfo on 4.5.1 and upwards.
85 85  * If you use the file upload component make sure you have the web server configured to disallow uploads over a certain size, otherwise your web/app server/adaptor/application can easily be denial-of-serviced (verb?) by uploading a large block of data.
86 -* If you implement user/password security at the application level ~-~- eg, by having a login panel on the Main page ~-~- consider overriding a global part of the request handling (such as session.appendToResponse) to check it's set on every request. Otherwise it's just too easy to sneak into your app via an accidental backdoor.
87 -* You can use web server authentication and check the headers on every request in somewhere like application.handleRequest ~-~- that way no unauthorised request can ever get processed by your app. If you want to be really careful, you could recompile the Adaptor to check these headers and not even pass the request to the applications.
94 +* If you implement user/password security at the application level - eg, by having a login panel on the Main page - consider overriding a global part of the request handling (such as session.appendToResponse) to check it's set on every request. Otherwise it's just too easy to sneak into your app via an accidental backdoor.
95 +* You can use web server authentication and check the headers on every request in somewhere like application.handleRequest - that way no unauthorised request can ever get processed by your app. If you want to be really careful, you could recompile the Adaptor to check these headers and not even pass the request to the applications.
88 88  Don't forget about the security implications of any direct actions you may have available in your application.
89 89  
90 90  You probably also want to check that your application server(s) and your database server's service ports are not open to the public internet. Normally, you only need 80 and 443 to the web server as the only communication (there are exceptions: You might want to allow 22 as well, for SSH administration,and perhaps even 21 for FTP access to some of the pages, etc.)
91 91  
92 -And all other normal server internet connection precautions... http:~/~/www.w3.org/Security/Faq/
93 -
94 -Category:WebObjects
100 +And all other normal server internet connection precautions... [[http://www.w3.org/Security/Faq/]]