jdeca568

There is one difference still, by downloading it locally, you only have to check it once and not everytime you want to use the script. You definitely have to trust more parties by piping from the web, and these parties could be compromised at some point. This might be fine, it depends on your own security policy.

Here is one: https://www.exploit-db.com/.

But this CVE doesn't appear to be referenced at the moment.

  paths | awk -F / '{ print $1 }'

(edit: format)

As mentionned several times already, OWASP has very interesting stuff, it's more web application oriented though. (https://www.owasp.org)

WebGoat is a good way to put things in practice locally. (https://github.com/WebGoat/WebGoat)

The project ZAP is a really great tool to help you in the process. (https://www.zaproxy.org)

Outside the web sphere, exploit database is a great site with a bunch of exploit code, explanation and papers. (https://www.exploit-db.com)

The tool suite in Kali Linux is also very good if you don't mind read the documentation and try understanding the goal of the tools. (https://www.kali.org)

Kali NetHunter lets you practice from Android. (https://github.com/offensive-security/kali-nethunter)

Security is such a wide domain that you can quickly get flood. I don't think the ultimate step-by-step learning guide exists.

Once you've learned and practiced a bit, if you don't give up too soon, you will get the point and understand how deep you need to go into a protocol or a system to actually do something yourself (then this not about security documentation anymore, but about understanding how the target works, and how you can make it work the way you want).

I would say that you need to focus on some targets first, and expand the scope over time depending on your needs/interests.

Well that's more of a manual work than anything else, not optimal in term of speed. Trying to keep following mailing lists diagonally, keep contact with other people in the niche. It eventually leads me to some other new site, mailing lists, blogs, videos. Then i use a bunch of scripts to maintain a todo list, and i'm processing (keep & index/drop) them when the time comes, and it loops.

TBH, i mostly do all of that just because i don't want to be stuck deeper in the Google web, but that's more of a philisophical issue. I could easily live without all the DDG stuff, but not (yet) without all the Google stuff.

I had the same problem with an almost automatic !g.

A while back i decided to put more effort and try to survive with !so, !gh, !hn, !r, !w, and a couple more depending on the context.

DDG may not give exact results in less than a second, but i believe that blindly giving priority to the fastest result is a critical issue, in many areas.

For the very niche topics, i basically maintain myself lists of sites.

I still use !g as fallback or when i'm too lazy. And also for pentest reconnaissance, i have a hard time seeing how to do it without Google honestly (which is scary).

Page load of DDG is not quite good indeed, but i don't mind let it a few seconds.

Everybody is guilty in some way of not making a change, or not taking a stand, whatever the 'good' or 'bad' subject that is.

Still, no single indvidual is to blame in most cases.

The education and the media in practice are means to shape the values, believes and perception of people. At the mass scale, people flows into an unstoppable current, growing, fed by itself.

Taking a stand against these currents from the outside would be suicide. (Fortunately there is not only one current to go into, yet).

FB will likely reach a dead end someday, but that sort of current will continue to flow.

IMHO, the best effort for an individual is trying to get other individuals realize and have some understanding in what kind of current they are flowing.

Cool, in the ~same vein, SBE is definitely worth a look.

https://github.com/real-logic/simple-binary-encoding

If i understand correctly, the problem of Java deserialization is 1) gadgets for code execution and maybe 2) DoS. And this is bad because even if it looks secure now, a gadget could be discovered later.

The default Java serialization is one of the easiest way to serialize instance of objects but there are many other ways, and many other risky ways among them.

It seems to be always the same problem: ClassLoader access. Couldn't there be a way to let the deserializers use a specific ClassLoader?

I mean some sort of (Sandboxed)ObjectInputStream that uses a specific ClassLoader defined in the JRE config. The sandboxed contexts could be defined in something like java.security, .policy, to define what it is supposed to know and when/where it is supposed to be used.