“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:
- OWASP Top 10 2017 – the ten most critical web application security risks
- PortSwigger Burp Suite (community edition)
- PHP Security Cheat Sheet
- Top 7 PHP Security Blunders
- The 2018 Guide to Building Secure PHP Software
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:
- Unleashing an Ultimate XSS Polyglot
- fuzz.txt – potentially dangerous files
- Payloads All The Things – a list of useful payloads and bypasses for web application security
- SecLists – a collection of different lists useful during the security testing
- IntruderPayloads – a collection of payloads, fuzz lists, and file uploads
- FuzzDB – a collection of fuzz lists and web application firewall evasion patterns
- payloads – a collection of payloads with links to a lot more lists and tools
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“).
What can we do with this method?
We can gather some basic information about the user, like the screen resolution (when the browser is maximized) and which browser (or engine) is used. Further we can detect if a user opens a link or hovers with the mouse over an element. This can be used to track which (external) links a user visits and using the hover method. It should be even possible to track how the user moved their mouse (using an invisible table of fields in the page background). However, using my method it’s only possible to track when a user visits a link the first time or hovers over a field the first time. Maybe it’s possible to modify the method so that it is possible to track every click.
Furthermore it is possible to detect if a user has installed a specific font. Based on this information it should be possible to detect, which OS a users uses (because different operating systems ship different fonts, e.g. “Calibri” on Windows).
“The 2018 Guide to Building Secure PHP Software” is an excellent guide to writing modern PHP applications with security in mind. It covers a bunch of the usual topics, but provides fresher solutions than most other similar guides.