Skip to Content
Last modified by Pascal Robert on 2010/09/13 00:22
From version 7.1
edited by Pascal Robert
on 2010/09/13 00:22
Change comment: There is no comment for this version
To version 5.1
edited by Pascal Robert
on 2007/09/03 17:04
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Development-Authentication and Security
1 +Web Applications-Development-Authentication and Security
Content
... ... @@ -28,42 +28,38 @@
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) ===
31 += The wotaskd config page (WO >~= 4.5) h3. =
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 ===
38 -
37 +The Monitor h3.
39 39  [[http://$HOSTNAME/cgi-bin/WebObjects/Monitor]]
40 40  
41 41  Monitor should be unavailable, or at least password protected.
42 42  
43 -=== The xyzzy default page ===
44 -
42 +The xyzzy default page h3.
45 45  [[http://$HOSTNAME/cgi-bin/WebObjects/xyzzy]]
46 46  
47 47  The name/password for the xyzzy page should be changed.
48 48  
49 -=== The WOStatisticsStore default page ===
50 -
47 +The WOStatisticsStore default page h3.
51 51  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOStats]]
52 52  
53 53  The statistics page should be protected by a password (or off).
54 54  
55 -=== The WOEventDisplay default page (WO >~= 4.5) ===
56 -
52 +The WOEventDisplay default page (WO >= 4.5) h3.
57 57  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventDisplay]]
58 58  
59 59  The events page should be be protected by a password (or off).
60 60  
61 -=== The WOEventSetup default page ===
57 +The WOEventSetup default page h3.
58 +[[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventSetup]]
62 62  
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]]
60 +See [[http://developer.apple.com/techpubs/webobjects/EOControlRef/Java/Classes/Concepts/EOEventCenterConcepts.html]]
64 64  
65 -=== You can invoke a WOComponent directly if you know its name ===
66 -
62 +You can invoke a WOComponent directly if you know its name h3.
67 67  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wo/$COMPONENTNAME.wo]]
68 68  
69 69  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.
... ... @@ -70,8 +70,7 @@
70 70  
71 71  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.
72 72  
73 -=== You can invoke a DirectAction if you know its name ===
74 -
69 +You can invoke a DirectAction if you know its name h3.
75 75  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONNAME]]
76 76  [[http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONCLASSNAME/$DIRECTACTIONNAME]]
77 77  
... ... @@ -82,8 +82,7 @@
82 82  
83 83  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.
84 84  
85 -= Others =
86 -
80 +Others h1.
87 87  And a few miscellaneous additions contributed by GarrickMcFarlane, a UK-based WebObjects consultant:
88 88  
89 89  * 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.