I have a user with the following policy permissions (!local,!telnet,!ssh,reboot,read,!test,!winbox,password,web,!sniff,sensitive,!api,!ftp,write,!policy) and they have the webfig skin below but immediately upon login they are sent to http://routerIPhere/webfig/ and all the skin Quick Set fields I've hidden are visible and interactive, it's only when I click Quick Set tab and I am taken to the quick set anchor does it hide everything properly.

Also, is this stuff actually secure? Assuming a user with the policy permissions above, can they still login to webfig and craft their own custom request to alter a hidden field? Is the security just on the presentation layer?

Using RouterOS 6.4, skin JSON attached.

I have a user with the following policy permissions (!local,!telnet,!ssh,reboot,read,!test,!winbox,password,web,!sniff,sensitive,!api,!ftp,write,!policy) and they have the webfig skin below but immediately upon login they are sent to http://routerIPhere/webfig/ and all the skin Quick Set fields I've hidden are visible and interactive, it's only when I click Quick Set tab and I am taken to the quick set anchor does it hide everything properly.

There are quirks in Design Skin... if you find bugs they can be reported to support [at] mikrotik.com, or you can submit a post here on the forum and mark the checkbox "Submit this post as a bug..." when you submit your post.

One way I've worked around this type of bug is to add a "status" page. It seems Webfig by default opens the status page after login IF you've added one. This may or may not work in your situation. I think you can add just about any item to the status page. Click the down arrow and select "Add to Status Page". In the left column make sure the Status menu is enabled.

Also, is this stuff actually secure? Assuming a user with the policy permissions above, can they still login to webfig and craft their own custom request to alter a hidden field? Is the security just on the presentation layer?

Official word is that it's not secure, as of 2 years ago.
http://forum.mikrotik.com/viewtopic.php?t=52184#p291758
http://forum.mikrotik.com/viewtopic.php?t=52184#p293904

Didn't seem to work for me, in FireFox or IE. What possible use-case is there for only having presentation-layer security? I can't think of any scenarios where you'd want to hide options and not prohibit access/modification of them.

I must be doing something wrong because it just flat out doesn't work now. I simply can't hide any fields under any circumstances on the Quick Set page. Read-only, notes, tabs and separators still seem to work though. Status page isn't useful for my scenario because it forces everything to be read-only. Essentially, all I wanted to do was limit the end-user to only changing the wireless password and ACL and having SSID, identity and WAN IP as read-only but if it's not actually secure anyway then it's probably all moot.

I'm seeing the same thing with the Quick Set page. It also seems kind of pointless that there are certain items you can't even turn off (graphs, buttons).

Attached is a sample skin where I've tried to create a setup like you're looking for. The Status page shows the read-only items, and the other menus allow you to edit the wireless security profiles (I assume that's what you meant by wireless password) and the ACL. The json file references the SSID and IP of my router, which will undoubtedly be different on yours. Just remove them from the Status page with the skin designer and add your own.

On the security note, I tried to access hidden menus by typing them directly in the browser (http://192.168.88.1/webfig/#Interfaces for example) but was unable to view them. That doesn't prove much, but it seems at least that you can't type them directly. I wonder what the official word is on current security status...

I'll take a look at the skin, thanks. Regarding the security, when I get some time I might try to develop a PoC of an exploit, assuming it is just presentation layer security. I had a quick look at the client-side JS engine and it's basically encapsulating and encrypting it's messages to the router within javascript and sending it via AJAX, probably just designed to provide at least some protection against passive MITM attacks over plain HTTP.
This design/problem plus things like only allowing FIPS 186-2 DSA SSH keys (Especially given NIST 800-57 4.2.4.1 recommendation of 2048bit for all new signatures) are starting to make me worried about other security issues, design choices and shortcuts that could be lurking in ROS.

I see what you've done, got rid of Quick Set and simply have status, the wireless tab and it's security profiles. Not ideal but workable enough, I think in the end I might just whip up a remotely configured solution instead so it's actually secured. Thanks for your help but I think the Webfig skins really do need more work on them before anyone can really seriously use them.

I'll take a look at the skin, thanks. Regarding the security, when I get some time I might try to develop a PoC of an exploit, assuming it is just presentation layer security. I had a quick look at the client-side JS engine and it's basically encapsulating and encrypting it's messages to the router within javascript and sending it via AJAX, probably just designed to provide at least some protection against passive MITM attacks over plain HTTP.
This design/problem plus things like only allowing FIPS 186-2 DSA SSH keys (Especially given NIST 800-57 4.2.4.1 recommendation of 2048bit for all new signatures) are starting to make me worried about other security issues, design choices and shortcuts that could be lurking in ROS.

Webfig Skinning was always designed to provide convenience, we have repeatedly said that it's not meant as a security measure. For that you can design a custom tool that uses the API, and whatever underlying security system that suits you.