At Openshift 4.x that recomends using
oc debug
instead ofssh
bellow I'll explain how to do it.
$ oc debug node/k8sdemo-hxvrp-master-2
# remember to change chroot /host
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.
Security Advisories / Bulletins / vendors Responses linked to Log4Shell (CVE-2021-44228)
javascript: Promise.all([import('https://unpkg.com/[email protected]?module'), import('https://unpkg.com/@tehshrike/[email protected]'), ]).then(async ([{ | |
default: Turndown | |
}, { | |
default: Readability | |
}]) => { | |
/* Optional vault name */ | |
const vault = ""; | |
/* Optional folder name such as "Clippings/" */ |
KEYMAPOPTS="us us" | |
HOSTNAMEOPTS="-n alpine" | |
INTERFACESOPTS="auto lo | |
iface lo inet loopback | |
auto eth0 | |
iface eth0 inet dhcp | |
hostname alpine | |
" | |
TIMEZONEOPTS="-z UTC" |
notify: | |
if: always() | |
name: Notify | |
needs: | |
- job1 | |
- job2 | |
- job11 | |
- job3 | |
- job4 | |
runs-on: ubuntu-latest |
The following describes a technique to achieve HTTP request smuggling against infrastructure behind a HAProxy server when using specific configuration around backend connection reuse. This was tested against HAProxy versions 1.7.9, 1.7.11, 1.8.19, 1.8.21, 1.9.10, and 2.0.5. Of all these tested versions, only 2.0.5 was not vulnerable out of the box, although it is when using the no option http-use-htx
configuration, which reverts back to the legacy HTTP decoder. 2.1 removed the legacy decoder so it is not affected.
To actually exploit HTTP smuggling using the issue described in this writeup, the backend server(s) behind HAProxy would also have to be vulnerable in the sense they too would need to suffer from a bug, but one which parses and accepts a poorly formed Transfer-Encoding header (almost certainly violating RFC7230), and allows HTTP keep-alive.
This is how HAProxy handles a request when Transfer-Encoding and Content-Length is p
def StandardUsernameCredentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(com.cloudbees.plugins.credentials.common.StandardUsernameCredentials.class, Jenkins.instance, null, null); | |
for (c in StandardUsernameCredentials) { | |
println(c.id + ": " + c.description) | |
} | |
def StandardUsernamePasswordCredentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials.class, Jenkins.instance, null, null); | |
for (c in StandardUsernamePasswordCredentials) { | |
println(c.id + ": " + c.description) | |
} |
/!\ Be very carrefull in your setup : any misconfiguration make all the git config to fail silently ! Go trought this guide step by step and it should be fine 😉
~/.ssh/config
, set each ssh key for each repository as in this exemple:import com.cloudbees.plugins.credentials.* | |
import com.cloudbees.plugins.credentials.common.* | |
import com.cloudbees.plugins.credentials.domains.* | |
import com.cloudbees.plugins.credentials.impl.* | |
import com.cloudbees.jenkins.plugins.sshcredentials.impl.* | |
import org.jenkinsci.plugins.plaincredentials.impl.* | |
// def item = Jenkins.instance.getItem("your-folder") |