4be667b606
working
2013-11-13 19:02:37 -05:00
af8776a3ea
halfway done A7
2013-11-13 18:23:38 -05:00
91e6797b40
adding broken functionality for A7
2013-11-13 18:23:38 -05:00
f0ca17df79
updating the information for A9 fixes #27
2013-11-13 11:47:29 -05:00
a65a20a647
Merge branch 'master' of github.com:OWASP/railsgoat into top-10-2013
2013-10-14 08:29:39 -04:00
8c17a3df0e
adding messaging function, needs tests...
2013-10-13 21:49:17 -04:00
8686f6b9d3
adding messages mvc to allow users to send messages.
2013-10-11 16:03:37 -04:00
e2c4fb4bd8
change to the user model based on a merge with master. Master is the correct code
2013-10-11 12:04:19 -04:00
bbed455178
verifying user exists before trying to update
2013-10-09 11:08:39 -04:00
73f3272aa1
adding flash message with validation errors, and redirect to sign_up
2013-10-07 15:23:37 -04:00
da061c79b6
intended to remove some of the weirdness when updating a users account. A blank password basically ends up causing the previously existing password to be hashed twice. Probably move to has_secure_password at some point although that may end up screwing up the intent of the particular tutorial item
2013-09-30 13:03:03 -04:00
ef8a9c1a46
merged with master
2013-09-27 21:55:50 -04:00
e0bca0139e
Added command injection Capybara spec.
2013-09-27 14:59:30 -05:00
825a972e4c
oops
2013-09-27 11:18:04 -04:00
c3562592c6
deleted some files
2013-09-27 11:17:16 -04:00
20420be1a6
Fixed logic to strip out user params.
...
Disclaimer: changes like these in this sort of app are tricky because
it's harder to presume the intention of the code in question.
The prior line:
```
user.update_attributes(params[:user].reject { |k| k == ("password" || "password_confirmation") || "user_id" })
```
returns an empty hash, because of the way the block evaluates:
```
irb(main):002:0> k = 'foo'
=> "foo"
irb(main):003:0> k == ("password" || "password_confirmation") || "user_id"
=> "user_id"
```
Before the last change to that line, without 'user_id' outside the
params, it didn't evaluate properly either:
```
irb(main):007:0> k = 'password_confirmation'
=> "password_confirmation"
irb(main):008:0> k == ("password" || "password_confirmation")
=> false
irb(main):009:0> ("password" || "password_confirmation")
=> "password"
```
So, in the normal use case for this form, you can't update any other
attribute of the User. To me, that's probably the best argument for
making this change, but it does simplify the SQL Injection attack
(although perhaps the prior complication was intended).
Before this change, injecting conditional SQL into the user_id param in
the account_settings update call would allow the password of whatever
account is found (e.g. the first one if injecting 'OR 1=1') to be reset,
but without additional attacks, the email address of that account is not
known.
After this change, the email address of that account now is also updated
in addition to the password, making it simpler to get in as an admin --
though you're still presuming the first account to be an admin.
2013-09-25 16:56:34 -05:00
d909f55ab9
initial write-up for gauntlt
2013-08-08 21:25:52 -04:00
ce6f32a1a2
working command injection in fileupload, closes issue #23
2013-07-09 16:36:03 -04:00
ea2014b637
I have exhausted all thoughts on how to actually get jquery file upload to work, so screw it, I am just going to make something homegrown for tomorrow
2013-07-09 13:53:00 -04:00
7b900bda2d
fixes issue #24
2013-06-10 16:25:14 -04:00
39d2e9d79f
finished CSRF/AJAX, closes issue #21
2013-06-06 22:40:52 -04:00
d445e59a98
this fixes issue #20 , seriously, no clue how I missed the missing constantize code
2013-06-06 16:43:58 -04:00
089e9540ac
finished admin filter and write-up for issue #6
2013-06-04 11:49:59 -04:00
ef2b2e8e11
okay, finally got a working redirect vuln
2013-06-04 11:00:01 -04:00
6d5623a423
changed SQLi vuln location, did write-up, closes issue #1
2013-06-03 12:31:34 -04:00
6528b56de6
added a sql injection vulnerability
2013-06-03 02:19:36 -04:00
2ac771ca50
Issue #3 can be closed, write-up and vuln complete for A4
2013-06-03 01:54:07 -04:00
14251e6f39
added Insecure dor vuln
2013-06-03 01:29:16 -04:00
88ea613da6
okay, write-up finished
2013-06-02 23:32:37 -04:00
86695e9e07
removed excess commented code
2013-06-02 22:42:50 -04:00
e97afb9bb4
added a very dangerous, very serious vulnerability (constantize
2013-06-02 22:42:29 -04:00
caecb88e30
prepping for constantize
2013-06-02 20:35:01 -04:00
570eafa01b
this closes issue #9
2013-06-02 20:19:31 -04:00
06dce1f8b2
I believe this has resolved the dependent destruction and we can close issue #18
2013-06-02 13:08:56 -04:00
4e445375fa
created the info disclosure write-up. Close issue #16
2013-06-02 12:39:04 -04:00
1267661c6a
seems the signup bug has been fixed, I would close this for now
2013-06-01 19:49:01 -04:00
0319cc4768
added a few things here. Firstly, I fixed the broken delete function with the admin page. Secondly, whenever you register for this application, we will automatically populate your user data to make the application functional. Seemed like the easiest way to do this
2013-06-01 00:19:07 -04:00
38fcc263bd
update account is now an ajax call
2013-05-31 22:10:32 -04:00
417aca2078
keeping changes up to date
2013-05-31 19:55:49 -04:00
6199beb780
we are going to fix this by automatically generating data for ppl that register HOWEVER, just in case that fails for some reason, I have applied a filter that ensures if some data is not associated with a person they cannot navigate to all aspects of the application. This is a preventive measure
2013-05-31 19:02:00 -04:00
c63275b3b3
dashboard figures actually indicate correct values now
2013-05-31 15:54:25 -04:00
4813ba9349
added visualization chart for performance history
2013-05-31 15:20:58 -04:00
379c442049
I have added the performance model, controller, route and seed data, now I am working on the actual visual aspects of the page
2013-05-31 14:45:31 -04:00
f8e21af3e0
added a new vulnerability plus completed the work info page
2013-05-31 11:41:54 -04:00
08a8c60276
added route, controller, model, sidebar link, and basic index page for the work info section so that we can render user data
2013-05-31 10:48:20 -04:00
a599ca9862
so now, when you add a PTO scheduled date, the calendar on your PTO page automatically updates to show this event :-)
2013-05-31 10:31:35 -04:00
a6a38c773e
added validation for all schedule fields (presence of) and working on a new way to dynamically update your calendar upon submission of a new calendar event
2013-05-31 00:31:13 -04:00
9d5cebbfa0
normalize
2013-05-30 16:05:03 -04:00
ff36b0fab5
working way to update your scheduled PTO
2013-05-30 12:11:50 -04:00
caf348f189
made some big changes here. The schedule had a has_one relationship with the PTO model. That is a problem since we only get one result back. meaning, a user cant have multiple scheduled events. This has been fixed with the use of has_many within the PTO model. Now, in relation to the PTO section, the next changes to happen are to be a fully functional create action that allows an event to be schedule, the form and controller has already been created. Umm, also, a calendar has been added and when we get the results back from a call to the create event action we will update that calendar. Think that is about it for now
2013-05-28 12:48:35 -04:00
cktricky