open-policy-agent/opa is an Open Source general purpose policy agent.
OPA gives you a high-level declarative language to author and enforce policies across your stack.
With OPA, you define rules that govern how your system should behave. These rules exist to answer questions like:
- Can user X call operation Y on resource Z?
- What clusters should workload W be deployed to?
- What tags must be set on resource R before it’s created?
You integrate services with OPA so that these kinds of policy decisions do not have to be hardcoded in your service. Services integrate with OPA by executing queries when policy decisions are needed.
When you query OPA for a policy decision, OPA evaluates the rules and data (which you give it) to produce an answer. The policy decision is sent back as the result of the query.
“Safe ways to do things in bash” is yet another guide to some of the best practices for writing bash scripts. It covers all the usual bits of quoting, escaping, error handling, and more.
“The headers we want” is a very simple, straight to the point blog post on the Fastly blog. Unlike many other more generic articles on the subject, it doesn’t try to explain the meaning of every HTTP header out there, and it doesn’t go into deep theory or the meaning of life, the universe and everything.
Instead it tells you plain and clear which headers should be emitted by your website or web application. And these cover everything from the usual Content-Type and Content-Length, all the way down to the CORS and Server-Timing.
Once the basic functionality of your website or web application is done and out of the way, this blog post comes in handy with the specific best practices to make your site more secure and much faster.
For more on the same subject, have a look at “The headers we don’t want” in the same blog.
“Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet” is a list of general recommendations and specific techniques to protect web applications against the CSRF attacks. That is, before the CSRF attacks will become obsolete.
“Understanding AD Access Control Entries” is a quick and simple article describing some of the madness of the Active Directory access control entities. This is particularly useful for those of us who had to deal with Active Directory, without having much experience with MS Windows. I’m sure this will come handy again in the future.
Chris Cornutt wrote “PREPARING FOR PENTESTING (@ LONGHORN PHP 2018)” blog post for his upcoming talk at the conference. I’d gladly attend the talk, but the time and place didn’t work out for me this time. Here are a few useful links from his blog post that might come in handy for anyone evaluating the security of their PHP application and preparing for the penetration testing:
The above are not a replacement for the talk, but if you are like me and can’t attend, these should at least get you started in the right direction.
This article (in Russian) lists a number of useful payloads (and some tools that work with them) for security testing of web applications. Below is the list of handy GitHub repositories for web server path testing, cross-site scripting, SQL injection, and several other common types of vulnerabilities. These payloads are much richer than basic hand-made tests and can help improve the security of the web application a great deal:
Awesome podcasts is a curated list of podcasts for software engineers. The list includes a whole lot of sections – one for each programming language out there, generic software engineering, tools, etc.
Also, have a look at this blog post I did a while back.
Here are some very exciting news from Let’s Encrypt:
We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.
ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.
Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.
Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.
Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.
I came across this blog post from a while back, which demonstrates how to use AES encryption for the data in MySQL database.
INSERT into user (first_name, address) VALUES (AES_ENCRYPT('Obama', 'usa2010'),AES_ENCRYPT('Obama', 'usa2010'));
SELECT AES_DECRYPT(first_name, 'usa2010'), AES_DECRYPT(address, 'usa2010') from user;
This seems rather easy and straightforward (apart from a little calculation one needs to do for the VARBINARY field types). The only thing that I’m concerned about is whether the encryption keys will be visible in the MySQL process list (as in “SHOW FULL PROCESSLIST“).