Skip to Content
Last modified by Pascal Robert on 2010/09/13 00:22
From version 5.1
edited by Pascal Robert
on 2007/09/03 17:04
Change comment: There is no comment for this version
To version 6.1
edited by Ray Kiddy
on 2009/11/18 12:30
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.kiddyr
Content
... ... @@ -28,38 +28,42 @@
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 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.
37 +=== The Monitor ===
38 +
38 38  [[http://$HOSTNAME/cgi-bin/WebObjects/Monitor]]
39 39  
40 40  Monitor should be unavailable, or at least password protected.
41 41  
42 -The xyzzy default page h3.
43 +=== The xyzzy default page ===
44 +
43 43  [[http://$HOSTNAME/cgi-bin/WebObjects/xyzzy]]
44 44  
45 45  The name/password for the xyzzy page should be changed.
46 46  
47 -The WOStatisticsStore default page h3.
49 +=== The WOStatisticsStore default page ===
50 +
48 48  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOStats]]
49 49  
50 50  The statistics page should be protected by a password (or off).
51 51  
52 -The WOEventDisplay default page (WO >= 4.5) h3.
55 +=== The WOEventDisplay default page (WO >~= 4.5) ===
56 +
53 53  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventDisplay]]
54 54  
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]]. See [[EventCenterConcepts>>http://developer.apple.com/legacy/mac/library/documentation/DeveloperTools/Reference/WO541Reference/com/webobjects/eocontrol/concepts/EOEventCenterConcepts.html]]
61 61  
62 -You can invoke a WOComponent directly if you know its name h3.
65 +=== You can invoke a WOComponent directly if you know its name ===
66 +
63 63  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wo/$COMPONENTNAME.wo]]
64 64  
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,7 +66,8 @@
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.
73 +=== You can invoke a DirectAction if you know its name ===
74 +
70 70  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONNAME]]
71 71  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONCLASSNAME/$DIRECTACTIONNAME]]
72 72  
... ... @@ -77,7 +77,8 @@
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.
85 += Others =
86 +
81 81  And a few miscellaneous additions contributed by GarrickMcFarlane, a UK-based WebObjects consultant:
82 82  
83 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.