I&#39;m with Jim, it does seem to me that they&#39;ve decided to hide functionality over implementing a more stringent access control solution. Sad that it still happens today. <br><br><div class="gmail_quote">On 12 April 2011 15:00, Jim Manico <span dir="ltr">&lt;<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Rick,<br>
<br>
Thanks for posting this. I respectfully submit that this seems like poor server side enforcement of Access Control/Authorization policy.<br>
<br>
Ive seen similar situations where sensitive data was hidden with CSS visibility style, something that I consider to be poor presentation-layer access control policy.<br>
<br>
Fair?<br>
<font color="#888888"><br>
Jim Manico<br>
</font><div><div></div><div class="h5"><br>
On Apr 12, 2011, at 2:52 PM, &quot;<a href="mailto:rick.mitchell@bell.ca">rick.mitchell@bell.ca</a>&quot; &lt;<a href="mailto:rick.mitchell@bell.ca">rick.mitchell@bell.ca</a>&gt; wrote:<br>
<br>
&gt; Good morning everyone, I was browsing through v3 this morning and it occurred to me that an issue I&#39;ve discovered in a number of apps recently isn&#39;t really covered by any part of v3 (please correct me if I&#39;ve somehow simply missed the section).<br>

&gt;<br>
&gt; The issue would fall under Authorization, maybe privilege escalation testing. I usually put it under a heading such as &quot;Enforcement of User Privileges by Elements within the User&#39;s Control&quot; when I prepare reports. Basically it boils down to developers hiding things from users or simply marking visible controls/elements as disabled and not performing any check server side for exercise of functionality.<br>

&gt;<br>
&gt; In one example I had a ReadOnly account to an administrative interface where I could &quot;setup&quot; users. Since my account was ReadOnly the &quot;Submit&quot; or &quot;Save&quot; button on the user creation page was set as &quot;Disabled&quot;. Using Firebug (or similar means) I simply removed the &quot;Disabled&quot; element on the button and was able to create new users since there was no check performed server side. The HTML in question was something like:<br>

&gt;<br>
&gt; &lt;input id=&quot;btnSave&quot; type=&quot;submit&quot; disabled=&quot;disabled&quot; value=&quot;Save&quot; name=&quot;btnSave&quot;&gt;<br>
&gt;<br>
&gt; I&#39;ve also encountered similar situations where the following HTML was in play:<br>
&gt;<br>
&gt; &lt;div style=&quot;display:none;&quot;&gt;<br>
&gt;<br>
&gt; I&#39;d be glad to write up some content for this when production of TG v4 content starts.<br>
&gt;<br>
&gt; Rick<br>
&gt;<br>
&gt; --------------------------------<br>
&gt; Rick Mitchell<br>
&gt; Security Analyst, Security Testing and Incident Response Team<br>
&gt; Bell Business Markets<br>
&gt; Phone: 613-785-4019<br>
&gt; Email: <a href="mailto:rick.mitchell@bell.ca">rick.mitchell@bell.ca</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Owasp-testing mailing list<br>
&gt; <a href="mailto:Owasp-testing@lists.owasp.org">Owasp-testing@lists.owasp.org</a><br>
&gt; <a href="https://lists.owasp.org/mailman/listinfo/owasp-testing" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-testing</a><br>
_______________________________________________<br>
Owasp-testing mailing list<br>
<a href="mailto:Owasp-testing@lists.owasp.org">Owasp-testing@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-testing" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-testing</a><br>
</div></div></blockquote></div><br>