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
c56dbe54a7
no change really
2013-09-11 10:58:46 -04:00
aab489ef40
fix for performance bug
2013-09-10 21:58:29 -04:00
6f71d7eda7
bug fix w/ the performance section
2013-09-10 21:57:03 -04:00
d5801f0684
Merge branch 'master' of github.com:OWASP/railsgoat into top-10-2013
2013-09-10 13:31:48 -04:00
69c180e845
minor changes to spec_helper and user model
2013-09-06 15:54:06 -04:00
17e082a63e
I believe the secure_compare tutorial is complete
2013-08-18 20:46:40 -04:00
5b6b88a4ba
fixed broken auth numbering and also the incorrect accordion labels within insecure_compare
2013-08-18 20:18:33 -04:00
bc74edf28d
lastest work towards the secure_compare tutorial
2013-08-18 20:10:36 -04:00
3c7a3fc9e4
still working on the timing attack prevention tutorial
2013-08-18 17:39:13 -04:00
979b6a229a
working on avoiding timing attacks piece
2013-08-17 21:27:33 -04:00
d909f55ab9
initial write-up for gauntlt
2013-08-08 21:25:52 -04:00
077e45c819
Merge branch 'master' of github.com:OWASP/railsgoat into top-10-2013
2013-08-08 16:59:14 -04:00
65eb2caeaf
made a suggestion based on digininjas comment on Rails tutorials blog post. Better to change method name to hash_password than encrypt_password
2013-08-08 16:57:58 -04:00
66445167bd
shifting tutorials
2013-07-28 19:59:03 -04:00
f67bd0f5ed
correct naming within the command injection tutorial
2013-07-28 19:44:51 -04:00
14c1fb367d
added a tutorial for command injection
2013-07-10 20:42:04 -04:00
82b5809bee
almost finished with the write-up for the command injection vulnerability
2013-07-10 11:41:36 -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
1a79471ef8
trying to fix a bug where you have to click twice on the tutorial credentials button
2013-06-20 11:28:29 -04:00
2e052828a6
taskbar / active enhancement
2013-06-16 00:49:28 -04:00
7b900bda2d
fixes issue #24
2013-06-10 16:25:14 -04:00
56381fe318
fixed issue #25
2013-06-10 15:27:21 -04:00
5ea8006fc1
closes issue #22
2013-06-07 09:05:11 -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
9d42453b05
removed pesky files
2013-06-04 16:00:30 -04:00
bdf3f20955
added a license
2013-06-04 14:17:12 -04:00
b76283910c
holding off on the last issue until i confirm whether or not oreoshake can cover secure headers here
2013-06-04 14:06:10 -04:00
bb2985018d
closes issue #7
2013-06-04 13:59:41 -04:00
089e9540ac
finished admin filter and write-up for issue #6
2013-06-04 11:49:59 -04:00
b0ace5ebef
added write-up for issue #8
2013-06-04 11:24:39 -04:00
ef2b2e8e11
okay, finally got a working redirect vuln
2013-06-04 11:00:01 -04:00
e1dfb8309c
finished the write-up for crytpo vuln, close issue #5
2013-06-03 18:08:21 -04:00
0b09e0d4c1
added the primary insecure crypto storage vuln
2013-06-03 12:52:24 -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
912c34a26e
finished the writeup for password complexity
2013-06-03 01:11:51 -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
cktricky